Instruction action archetypes?
Hello Erik, I will provide you a quick answer, but I'll reply to the list so other may comment as well. Instructions and Actions are both entry subtypes but the difference is that Instructions tell what the planned activities were and Actions tell which actual actions were taken. They are meant to be recorded separately and since the instruction state machine (ISM) used in openEHR is coded by the support terminology the available states are static and every recorded action will cause a care flow step to be taken (which has an optional description) that defines a transition state in the ISM. Also note that if the action was caused by an instruction the action will hold instruction details that reference the instruction and activity that was planned for the action. Best wishes, Mattias 2007/5/25, Erik Sundvall erisu at imt.liu.se: Hi! Some (possibly stupid) questions: - Are there any examples of instruction archetypes with more than one activity anywhere? - If different activities (of the same instruction) point to different action archetypes how should then the resulting usage of the ISM be interpreted? Can they be considered part of the same process with some states in each action archetype? A swift reply to one or more of the questions would be very welcome. Best regards, Erik Sundvall http://www.imt.liu.se/~erisu/ ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070525/ff209734/attachment.html
Error in terminology.xml?
Hi Bert, Yes, I believe it should be changed. I actually made a heading change for the subject setting in the GUI of the archetype editor when I saw that the subject attribute of the ENTRY classes should be a PARTY_RELATED (which represents the relation to the subject of data) and not a PARTY_SELF (which represents the subject of data). For some reason I never realized that the terminology.xml was wrong. Regards, Mattias 2007/3/16, Bert Verhees bert.verhees at rosa.nl: This line is in it: Concept Language=en ConceptID=32 Rubric=Subject of data / when you go to grouper: Grouper id=1 ConceptID=32 / and then to groupedconcept: GroupedConcept GrouperID=1 ChildID=0 / GroupedConcept GrouperID=1 ChildID=3 / GroupedConcept GrouperID=1 ChildID=6 / GroupedConcept GrouperID=1 ChildID=7 / etc which points to: Concept Language=en ConceptID=0 Rubric=self / Concept Language=en ConceptID=3 Rubric=foetus / Concept Language=en ConceptID=6 Rubric=donor / Concept Language=en ConceptID=7 Rubric=maternal grandmother / etc... I wonder if the above (first) line should be Concept Language=en ConceptID=32 Rubric=Related party relationship / because this is also in the PDF-documents: terminology.pdf page 22 and in support_im.pdf, page: 59 Thanks, bert ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070316/85cd43b2/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Problem in some sample archetypes and questions
2007/1/8, Koray Atalag atalagk at yahoo.com: Currently both the Editor and the Workbench allow these type of errors. Hi Koray, The latest code of the Java Archetype Editor now validates cardinalities. It also has support for all but the demographics archetypes now. Lots of new improvements and features have been added and version 0.5 of the editor (including the source code) will be released before the end of this month. Regards, Mattias Forss -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070108/fd5b8126/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Problem in some sample archetypes and questions
2007/1/8, Thomas Beale Thomas.Beale at oceaninformatics.biz:
Koray Atalag wrote:
QUESTION-1: What is the correct approach for above problem?
as Sam has said your understanding is correct and the archetype is in
error.
QUESTION-2: Assume in some other place in the archetype you reference
the ELEMENT node with occurences {0..8} by use_node. And in this
particular place you do not want to have up to 8 instances and but also
you want it to be mandatory (i.e. 1..) or even want {3..5}. What is the
solution? (other than writing the whole thing once again)
the current semantics are that the occurrences of the referenced node
are what takes effect. However, I agree that a preferable approach would
be if the occurrences could be overridden at the origin point of the
use_node reference. This would not be incompatible with the current
semantics, and would probably be a useful change. What do others think?
[Particularly the Archetype tool authors]?
Hi Thomas,
I think it would be a good idea to let the users of the archetype editors
override occurrences of referenced nodes.
Regards,
Mattias
Note that in the AOM, an
ARCHETYPE_INTERNAL_REF inherits occurrences from C_OBJECT, so in theory
our archetype parsers should handle them, but I have just looked at
mine, and it doesn't...Rong, how about the Java parser? (So much for
having complete test archetype coverage;-)
QUESTION-3: Related with second question, I also need to disallow usage
of some values when referencing by use_node entries. This I believe is
not an uncommon requirement in clinical medicine.For me I have an
element with a long list of values of sites of an organ (Esophagus,
stomach, colon and so on) and in many places of an observation these
sites repeat without change so I can reference original. But in some
cases selection of certain site(s) is not logical and should better be
restricted or selection of only one site makes sense. What is the
solution?
I actually think there are various solutions here...
* the most obvious would be that at the point of reference, you create a
CLUSTER node, and then individually reference the subset of paths of
items from the target CLUSTER that you want, but not others.
* another one would be to make a number of ITEM_TREE or ITEM_LIST
archetype of the relevant piece of content as separate archetypes, and
use slots to include particular subsets.
* a third possibility is to use invariants to prevent certain paths from
existing that would otherwise be allowed by the main part of the
definition of the archetype.
- thomas beale
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070108/41812477/attachment.html
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
[Norton AntiSpam] Re: Problem in some sample archetypes and questions
Hi Jose,
I don't think the meaning of the node will not change, but it depends on how
you define it. If we think of the reference node (use_node) as a shortcut to
an entry form. Also think of it as if that shortcut decided how many times
the same entry form would show up. If we override the occurrences we don't
change the meaning of the entry form.
However, if the original meaning of having for example 2 occurrences of a
node we're referencing is to enter observations about two different sites
(say internal and external) and if we are allowed to override those
occurrences, then the original purpose of the node is not fulfilled because
it allows entry to be made less or more times.
This was probably not a full answer to your question.
Regards,
Mattias
2007/1/8, Jose Alberto Maldonado jamaldo at upvnet.upv.es:
Hi all,
we have a doubt regarding the possibility of overriding occurrences of
referenced node. The main concern has to do with the fact that a occurrence
constraint is part of the semantics of the node being constrained. If it
is true, when overriding the occurrences of referenced nodes, do we change
the meaning of the original node and therefore the description (and even
terminology binding) might become erroneous?.
best regards
Mattias Forss escribi?:
2007/1/8, Thomas Beale Thomas.Beale at oceaninformatics.biz:
Koray Atalag wrote:
QUESTION-1: What is the correct approach for above problem?
as Sam has said your understanding is correct and the archetype is in
error.
QUESTION-2: Assume in some other place in the archetype you reference
the ELEMENT node with occurences {0..8} by use_node. And in this
particular place you do not want to have up to 8 instances and but
also
you want it to be mandatory (i.e. 1..) or even want {3..5}. What is
the
solution? (other than writing the whole thing once again)
the current semantics are that the occurrences of the referenced node
are what takes effect. However, I agree that a preferable approach would
be if the occurrences could be overridden at the origin point of the
use_node reference. This would not be incompatible with the current
semantics, and would probably be a useful change. What do others think?
[Particularly the Archetype tool authors]?
Hi Thomas,
I think it would be a good idea to let the users of the archetype editors
override occurrences of referenced nodes.
Regards,
Mattias
Note that in the AOM, an
ARCHETYPE_INTERNAL_REF inherits occurrences from C_OBJECT, so in theory
our archetype parsers should handle them, but I have just looked at
mine, and it doesn't...Rong, how about the Java parser? (So much for
having complete test archetype coverage;-)
QUESTION-3: Related with second question, I also need to disallow
usage
of some values when referencing by use_node entries. This I believe
is
not an uncommon requirement in clinical medicine.For me I have an
element with a long list of values of sites of an organ (Esophagus,
stomach, colon and so on) and in many places of an observation these
sites repeat without change so I can reference original. But in some
cases selection of certain site(s) is not logical and should better
be
restricted or selection of only one site makes sense. What is the
solution?
I actually think there are various solutions here...
* the most obvious would be that at the point of reference, you create a
CLUSTER node, and then individually reference the subset of paths of
items from the target CLUSTER that you want, but not others.
* another one would be to make a number of ITEM_TREE or ITEM_LIST
archetype of the relevant piece of content as separate archetypes, and
use slots to include particular subsets.
* a third possibility is to use invariants to prevent certain paths from
existing that would otherwise be allowed by the main part of the
definition of the archetype.
- thomas beale
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
___
openEHR-technical mailing listopenEHR-technical at
openehr.orghttp://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Jose A. Maldonado. Ph. D.
Bioengineering, Electronic and Telemedicine Group
Escuela Universitaria de Informatica
Technical University of Valencia
Camino Vera s/n
46022 VALENCIA (Spain)
Tel. + 34 96 387 70 07 ext: 75277
e-mail: jamaldo at upvnet.upv.eshttp://bet.upv.es
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr
Preprint re: SNOMED codes
2007/1/3, Andrew Patterson andrewpatto at gmail.com:
The system at present is performing mappings on pre-modeled archetypes
depriving it the luxury of having access to the author.
This is what I meant by the 'split' case - a split between the
people/group
constructing the archetype, and the people doing the binding (in this
Sam writing the archetype and you guys doing the terminology stuff). It
doesn't lessen your points about the difficulties of doing the terminology
mapping - I just wanted to clarify that the plan in the 'best case' is
that there wouldn't be so much of a split (i.e. you'd be in communication
with the people writing the archetype, or it would all be done within one
tool by the same author)
I agree that this URL feature sounds a bit complex. Not having complete
knowledge of the Ocean methodology and objective makes it rather
difficult
to comment though. However, 'is_a' trees are only part of the solution
to
the binding/mapping process. There are a few archetypes that have 'is_a'
terms and can be dealt with in a less complex way i.e. without the use
of
URL's.
Other than actually enumerating the term codes in the ADL file, what other
mechanism is there other than URLs?
Though am not sure whether the Ocean team had something else in mind
when using URLs.
The URL system is not inherently bad - it solves the problem in a
relatively clean way that allows lots of room for future developments
in terminologies without constraining the solutions. I just worry that
with complex terminologies like snomed being used more often
it may be useful to have an inbetween solution i.e.
simplest)
list of codes typed in '123123', '3242342', '123123'
* moderate *)
simple langauge like limit depth 5 (is_a('102323','arm fracture'))
complex)
http://www.termserver.com/saved_query?realm=ukconcept_root=1231231
Hi,
Within our team in Link?ping we've discussed the potential of using OWL as a
query-language for constraint bindings. It might be something worth looking
into.
Regards,
Mattias
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070104/4bb7dd4f/attachment.html
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
[Norton AntiSpam] Re: Re: Suggestions re Term binding in Archetype Editor
2006/12/19, Williamtfgoossen at cs.com Williamtfgoossen at cs.com: In een bericht met de datum 18-12-2006 18:00:54 West-Europa (standaardtijd), schrijft mattias.forss at gmail.com: Maybe you're right, the definitions could be added as comments, but for proprietary terminology like SNOMED CT this will mean that these kind of archetypes can only be distributed to people that have paid the license. Sorry, but Snomed CT cannot be considered a proprietary terminology given the formal international SDO status from January onward. We'll see about that. Read about the issues with SNOMED and LOINC here http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_032401.html Mattias Further, most English speaking countries (Cnd, UK, US, Aus, Nw Zealand) already have a national licence allowing everyone to use it for health purposes. William Goossen ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061219/cc6df49c/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Suggestions re Term binding in Archetype Editor
Hi Ian, Archetypes are designed to be loosely coupled with terminology so that they can be used when there are no terminology resources available. If we have comments of the bindings, we get another problem because if the definition of the binding changes (for example a translated term is redefined in a terminology) the comment will be obsolete. We currently have to rely on the archetypes' local terminology to get the approximate rubrics when there are no terminology resources available. Regards, Mattias 2006/12/18, Ian McNicoll ian at gpacc.co.uk: Hi Sam, I appreciate the language difficulty here, given the ontology separation in ADL. However, in the UK context, the ability to document bindings to Snomed-CT with clear documentation, thereof, will be crucial to promoting OpenEHR. The design philosophy for DV_CODED_TEXT is that the raw term is never sent without the rubric, and I think somehow this needs to be extended to the binding terms as it is by no means certain that access to a terminology server will be a given in all the environments where ADL is being used as a design / documentation language. Would it be possible to allow the term bindings to be commented with the term name in the native authored language(as the current dADL entries are commented with the node name )? The current editor seems to strip out the any comments from the term bindings. This would at least let the rubrics be captured and displayed in any documentation. Ian From: Sam Heard [mailto:sam.heard at oceaninformatics.biz] Sent: 18 December 2006 00:22 To: For openEHR technical discussions Subject: Re: Suggestions re Term binding in Archetype Editor Version 1 candidate does this and will be out soon Ian - it does not include the SNOMED text as this will be different in different languages. Sam Ian McNicoll wrote: Hi, I am currently working my way slowly through the Scottish Cardiac dataset, converting it to archetypes as proof-of-concept, using the OE editor. Term binding (to SNOMED) will be a crucial aspect from our perspective, especially binding local (interface) terms to SNOMED concepts. This would be much easier within the editor if the Term bindings screen displayed the node name as well as the Node ID, as it is easy to forget which local term you are trying to bind by the time you have rummaged around in Snomed for a bit!!. The Choose Nodes dialog might also be a little easier if the Node parent name and Node name were included. When only the node name is visible this can cause confusion if similar local terms are used for different nodes e.g. Not known. Finally in the ADL, I think it would be very helpful to be able to include the text of the Bound term text as well as its code. This would allow much easier checking for errors and documenting I have done this by enclosing the bound term text in [] for now. e.g. term_binding = [SNOMED-CT] = items = [at] = [SNOMED-CT::229819007 [Tobacco use and Exposure]] [at0006] = [SNOMED-CT::?Non Tobacco user] [at0009] = [SNOMED-CT::] [at0011] = [SNOMED-CT::[Ex-smoker] 8517006] [at0012] = [SNOMED-CT::[Current non-smoker] 160618006] Regards, Ian ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. Ltd. Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) Ph: +61 (0)4 1783 8808 Fx: +61 (0)8 8948 0215 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061218/4836d639/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Suggestions re Term binding in Archetype Editor
2006/12/18, Ian McNicoll ian at gpacc.co.uk: Hi Mattias, I do appreciate these difficulties but if the definition of the binding changes the binding itself may be obsolete. If the binding changes so much in the terminology that it may be obsolete in the archetype it would probably lead to a new term that is created in the terminology and the old one is kept... but that doesn't matter in this discussion - just wanted to point it out. I agree the comment idea is less than satisfactory, it would be better if the term binding contained the rubric as well as the term code for exactly the same reasons that the rubric must always accompany the term code in DV_CODED_TEXT. I don't know why the DV_CODED_TEXT is designed this way. I have thought about it and the only reason why this is done is probably to get a faster access to the rubric and maybe also when there are no translations for the term in a specific language in order to get a 'default' rubric at all times. Maybe you're right, the definitions could be added as comments, but for proprietary terminology like SNOMED CT this will mean that these kind of archetypes can only be distributed to people that have paid the license. Regards, Mattias Managing Snomed-CT is going to be a very tricky exercise. Using archetypes + bindings offers a very powerful way of managing Snomed where semantic precision is very important e.g. decision support. Having tools that will let us design and document these bindings will be a powerful way of persuading those who have yet to understand the value of the archetype approach. Having the term rubrics available is an important part of cross-checking that the correct binding has been applied, both for the original author (where terminology services might well be available) and when the archetype and bindings are reviewed by a wider clinical audience (when such services may not be available). Regards, Ian -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061218/854befbb/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
[Norton AntiSpam] Re: DV_QUANTITY_RATIO - remove from specification
2006/12/8, Thomas Beale Thomas.Beale at oceaninformatics.biz: Mattias Forss wrote: Does this mean that the ratio constraint could as of now be removed from the archetype editors? Will the DV_RATIO class be removed from the specifications as well? If not, should the editors change the current ratio constraint to be of a DV_RATIO instead of a DV_QUANTITY_RATIO? this is the expected approach. I know it is annoying for us to make this software change, but we cannot escape the fact that there were some categories of clinical data that were not properly addressed by the current data types. Not sure what your answer is here, can the ratio constraint be removed from the editors or not? I think that the new DV_PROPORTION class could be used instead of DV_QUANTITY when there are no units, e.g. only the property 'Qualified real' and the empty string as a unit or a missing unit attribute in the item list of C_QUANTITY and only a magnitude attribute. The current ADL parser doesn't expect empty or null units which is correct according to the specification of C_QUANTITY_ITEM in the archetype profile package. Hence, there should always be a unit specified for each item in the item list of C_QUANTITY in archetypes and it cannot be empty because quantified data with no units could be represented with the DV_PROPORTION data type, right? DV_COUNT will take care of countable things - also with no units. Otherwise, anything else with no units I think will end up being a DV_PROPORTION - is we think of proportion as the idea of relative amount, how much of a total, then it is quite a wide concept that is likely to cover many situations. Sam and I believe your assumption is pretty safe at the moment. Understood, the proportion data type makes a lot more sense than the DV_QUANTITY_RATIO which allowed a lot of different quantifiable data types. There is no need to make things more complicated than they are and the simplification with DV_PROPORTION is great. If you have a look at the blood film archetype (here: http://my.openehr.org/wsvn/knowledge/archetypes/dev/adl/openehr/ehr/entry/observation/openEHR-EHR-OBSERVATION.blood_film.v1.adl?op=filerev=0sc=0) you will see that the elements named 'Packed cell volume (PCV)' and 'Plateletcrit' are quantity data types with empty units, but maybe they could be changed to proportion data types instead? If not, then the specification of C_QUANTITY_ITEM must be changed. Sam - I imagine this is right - can you check this? Although we have not yet uploaded cleaner archetypes with all the changes everyone wants, we have nearly done all the changes to the tools, and the next generation of archetypes on the openEHR website should address everything. After that we should be able to proceed faster, since I think we will have removed all the anomalies in tools with respect to the specification, and also fixed a few anomalies in the specfication. It would be great if the archetypes could be updated soon. Could I get a listing of the changes so I can update the Java archetype editor accordingly? Regards, Mattias -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061208/32ffad79/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
[Norton AntiSpam] Re: DV_QUANTITY_RATIO - remove from specification
2006/11/30, Sam Heard sam.heard at oceaninformatics.biz: Dear All We have been working on the data types as we have known that there is a need to deal with fractions, ratios and percentages when the idea is of proportion - ie there is no units. Since the DV_QUANTITY_RATIO points to anything Quantified (ie count, date_time, duration) there are many non-sensible possibilities and although it has been around since the GEHR days, we have not used it for anything other than the idea of the new DV_PROPORTION type (which will be available in 1.0.1). Hi Sam, Does this mean that the ratio constraint could as of now be removed from the archetype editors? Will the DV_RATIO class be removed from the specifications as well? If not, should the editors change the current ratio constraint to be of a DV_RATIO instead of a DV_QUANTITY_RATIO? I think that the new DV_PROPORTION class could be used instead of DV_QUANTITY when there are no units, e.g. only the property 'Qualified real' and the empty string as a unit or a missing unit attribute in the item list of C_QUANTITY and only a magnitude attribute. The current ADL parser doesn't expect empty or null units which is correct according to the specification of C_QUANTITY_ITEM in the archetype profile package. Hence, there should always be a unit specified for each item in the item list of C_QUANTITY in archetypes and it cannot be empty because quantified data with no units could be represented with the DV_PROPORTION data type, right? If you have a look at the blood film archetype (here: http://my.openehr.org/wsvn/knowledge/archetypes/dev/adl/openehr/ehr/entry/observation/openEHR-EHR-OBSERVATION.blood_film.v1.adl?op=filerev=0sc=0) you will see that the elements named 'Packed cell volume (PCV)' and 'Plateletcrit' are quantity data types with empty units, but maybe they could be changed to proportion data types instead? If not, then the specification of C_QUANTITY_ITEM must be changed. Another issue not at all related to the above: The Ocean editor writes other_contributors = in the description part when there are no other contributors, but since the attribute is not mandatory, garbage like this should be removed from the archetypes. If the attribute exists, then it should contain something as well. I would like this to be fixed, because it makes the Java ADL parser fail... Regards, Mattias I have filed a change request which explains how the perceived requirements for this type have largely been dealt with in archetypes: http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/227/base_view?portal_status_message=Your%20changes%20have%20been%20saved.fieldset=issuedata Tom will let you know about the DV_PROPORTION class. http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/144/base_view?portal_status_message=Your%20changes%20have%20been%20saved.fieldset=issuedata Interested in comments and queries... Cheers, Sam -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. Ltd. http://www.oceaninformatics.biz/Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) *Ph: +61 (0)4 1783 8808* *Fx: +61 (0)8 8948 0215* ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061207/ff44a8c3/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Constraint references
Hi all, I'm wondering what the difference is between a CONSTRAINT_REF and a C_DV_CODED_TEXT that has the query attribute set? The descriptions of the two are the following: CONSTRAINT_REF class description: Reference to a constraint described in the same archetype, but outside the main constraint structure. This is used to refer to constraints expressed in terms of external resources, such as constraints on terminology value sets. Description of query attribute of C_DV_CODED_TEXT: Constraint in terms of an abstract query expression to be addressed to a terminology server. Is there a syntactic difference between the two in ADL? Mattias -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061122/b52e3eaf/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
2006/11/21, Sam Heard sam.heard at oceaninformatics.biz: The Ontology is so huge I have wondered about having the Text and Description as attributes - it would save a lot of space and I do not think it would complicate things at all. What do others think? Sounds like a good idea as long as the two parts (text, description) of the description items will remain. If more parts are added though, it is not a flexible solution. Mattias Cheers, Sam -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061121/83340f4a/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
[Norton AntiSpam] Re: XML serializer (retry due to too large message)
Hi Heath, I know that the C_MULTIPLE_ATTRIBUTE class has a property of 'members' in the AOM (since I know the AOM very much in detail), but it's not in the XML schema specification. I have not followed the AOM, because I thought I was only supposed to look at the schema. Here's the XML schema and XML instance of C_MULTIPLE_ATTRIBUTE with the property 'children' and not 'members' as in the AOM: http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h783584366.html . If you could explain a bit more which strategy I should use when generating XML instances I would be very grateful. It seems you suggest I should follow the AOM more closely instead of the XML schema of AOM and its instance representations. By the way, your second example representation of 'members' is similar to Andrew's example and not mine. I have one container element called 'children', but no xsi:type specified. Where do you get the item element name from? I can't find it neither in the XML schema nor the AOM. Regards, Mattias 2006/11/17, Heath Frankel heath.frankel at frankelinformatics.com: Mattias, You don't seem to follow the AOM when generating your XML instances. For example, the C_MULTIPLE_ATTRIBUTE class has a property of 'members' which is a list of C_OBJECT. This property name should be used in the XML instance so you would get: attributes xsi:type=at:C_MULTIPLE _ATTRIBUTE members item xsi:type=C_COMPLEX_OBJECT.../item item xsi:type=C_COMPLEX_OBJECT.../item /members /attributes The alternative is to have the following but I suggest that members is not quite right similar to your use of children below. attributes xsi:type=at:C_MULTIPLE _ATTRIBUTE members xsi:type=C_COMPLEX_OBJECT.../members members xsi:type=C_COMPLEX_OBJECT.../members /attributes I would also suggest that we should follow the AOM more closely and use an existence element rather than minOccurs and maxOccurs. What you are doing by using the later is mimicking ADL rather than following the AOM. Therefore you would get by following based on the openEHR RM for the Interval type. attributes xsi:type=at:C_MULTIPLE _ATTRIBUTE existence lower xsi:type=xs:int1/lower upper xsi:type=xs:int1/upper ... /existence members item xsi:type=C_COMPLEX_OBJECT.../item item xsi:type=C_COMPLEX_OBJECT.../item /members /attributes Regards Heath -- *From:* openehr-technical-bounces at openehr.org [mailto: openehr-technical-bounces at openehr.org] *On Behalf Of *Mattias Forss *Sent:* Friday, 17 November 2006 8:16 AM *To:* For openEHR technical discussions *Subject:* Re: XML serializer (retry due to too large message) Hi Andrew, I looked at your example and I think it could be a good way to use xsi:type to indicate sub-types where the number of children elements are specified to be only one. This will mean that we don't need to add an extra sub-element, e.g. description xsi:type=RESOURCE_DESCRIPTION (details here: http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h439624612.html). However, I don't think the XML schema specification of the AOM explicitly state that xsi:type should be in XML archetypes. I would appreciate if openEHR published some XML archetypes that exemplified the standard way to express them. I don't like the idea of having several ways of representing archetypes in XML so it would be nice if some examples were out to lead the way. When there are more than one child inside an element, the idea with xsi:type requires us to repeat the container element for each child instead of placing all children inside a single container element, so you have attributes xsi:type=at:C_MULTIPLE _ATTRIBUTE minOccurs=1 maxOccurs=1 ... children xsi:type=C_COMPLEX_OBJECT.../children children xsi:type=C_COMPLEX_OBJECT.../children /attributes instead of attributes xsi:type=at:C_MULTIPLE _ATTRIBUTE minOccurs=1 maxOccurs=1 ... children C_COMLEX_OBJECT.../C_COMPLEX_OBJECT C_COMLEX_OBJECT.../C_COMPLEX_OBJECT /children /attributes The first example is of course more compact, but the element name children doesn't make sense, since it doesn't contain all of the attribute's children. The second example will collect all the children in one single container element, but again, I don't know what the specification mean with the occurrences brackets, e.g. what does [0..*] refer to in children C_OBJECThttp://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h-1665829344.html/children [0..*] ? Does it refer to the children element or to the C_OBJECT element? This should be clarified. I have been dealing a lot with ADL and I can
XML serializer (retry due to too large message)
2006/11/17, Andrew Patterson andrewpatto at gmail.com: I know that the C_MULTIPLE_ATTRIBUTE class has a property of 'members' in the AOM (since I know the AOM very much in detail), but it's not in the XML schema specification. I have not followed the AOM, because I thought I was only supposed to look at the schema. The AOM is at fault in this instance - the AOM has a field defined in C_ATTRIBUTE called 'children', and then proceeds to rename this field to 'attributes' and 'members' in the two subclasses C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE. This of course is not really implementable in any OO style language or XML.. the XML schema does the correct thing and just defines 'children' in the base C_ATTRIBUTE class. No, it proceeds to rename this field to 'alternatives' (not attributes) and 'members'. I agree, that it's not OO style, but why isn't it implementable in XML? XML isn't OO, it's just a way of storing structured information, and the guys building the XML parsers to create the AOM objects again can probably deal with that. But since the AOM is OO I guess it wouldn't be a bad idea if the contents of the XML instances were in OO style. Mattias I have followed the XSD exactly in my serialization.. I believe the intention is that the archetype XSD reflects the AOM model 1:1 (as much as possible). I see the archetype XSD as a formal definition of the cotnent of the AOM document. Andrew ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061117/e9597093/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
2006/11/17, Heath Frankel heath.frankel at frankelinformatics.com: The AOM is at fault in this instance - the AOM has a field defined in C_ATTRIBUTE called 'children', and then proceeds to rename this field to 'attributes' and 'members' in the two subclasses C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE. This of course is not really implementable in any OO style language or XML.. the XML schema does the correct thing and just defines 'children' in the base C_ATTRIBUTE class. I have followed the XSD exactly in my serialization.. I believe the intention is that the archetype XSD reflects the AOM model 1:1 (as much as possible). I see the archetype XSD as a formal definition of the cotnent of the AOM document. Oh, so that's why I got confused why members was implemented as a method rather than an attribute, I didn't make the correlation between members and children (perhaps I should have read the words rather than just the picture :). Oops, I also missed that it was a function :-) Maybe the specs could distinct attributes, functions, etc with different coloring. In that case, the XML schema does not require a change request for this issue. I would still like to explore the use of an existence element rather than minOccurs and maxOccurs attributes. I don't see why existence and occurrences in C_OBJECT are treated differently. And then I think the interval_of_integer type should use elements lower and upper as per the Interval assumed type specified in the openEHR Support package. Agree Mattias Heath ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061117/4c22b4b0/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
[Norton AntiSpam] Re: XML serializer (retry due to too large message)
2006/11/17, Bert Verhees bert.verhees at rosa.nl: Bert Verhees schreef: Mattias Forss schreef: Well, I'm no expert on XSD since I never cared about learning it... but if I go back to your example, why didn't you use xsi:type in some places, for example: I don't know if you ever saw this site, I did, it was helpful http://www.w3schools.com/schema/default.asp (forgot ;-) Yes, the tutorials by W3 schools are nice, but most often not as detailed as one might wish. //Mattias Bert ___ openEHR-technical mailing list openEHR-technical at openehr.orghttp://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061117/b24322db/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
Andrew, In your example, you have the other_contributors element even when it has no children, but the schema specification says that it's optional, i.e. other_contributors list_of_stringhttp://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h-2045140803.html/other_contributors [0..1]. Shouldn't you discard that element when the list of contributors is empty? /Mattias 2006/11/16, Andrew Patterson andrewpatto at gmail.com: description other_contributors / lifecycle_stateAuthorDraft/lifecycle_state -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061117/f07d1cab/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype questions
2006/11/13, Rong Chen rong.acode at gmail.com: I am not sure if it's safe to allow cross-use of internal archetype nodes for data entering. A better approach in my view is to separate the common archetype node into a standalone archetype and include it in other archetype or template. For read-only purpose, DV_EHR_URI is perhaps a solution. Good answer Rong. There should probably only exist one archetype for data creation of specific nodes and URIs can be used to get certain values if needed, for example if the BMI is entered with another template that uses weight data of a patient. However, some archetype authors might not understand this idea and must probably be trained in archetype modeling. The higher quality archetypes there exist, the better the EHR systems will perform. Mattias Cheers, Rong -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061113/edc3c466/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype questions
2006/11/13, Thomas Beale Thomas.Beale at oceaninformatics.biz: Hi Matiass, Mattias Forss wrote: Archetype A and archetype B will have 'correct archetype paths according to where the fragment was put', but will they refer to the same paths? When I talked about data I meant what was stored in the EHR system and when I talked about values I meant what was entered in the template. I tried to ask if there is some way to make two or more archetypes manipulate exactly the same data in an EHR system, meaning that the archetypes probably must refer to the same paths - otherwise the data will be manipulated at different places and the system must know that the data at the different places are actually the same. Consider this example: Archetype A is used in a template to create data about a patient's weight and archetype B is used in another template and will also create data about the weight. However, if the weight data was already entered in the EHR system, is there a way (to create archetypes) which make the system know that it deals with the same data no matter if it came from archetype A or archetype B and fetch the last entered value to any of the templates that need the weight information? Ah, I understand where you are coming from now. Archetypes and templates don't know anything about which data instances they have created; it is the other way round. A given template could be used to create 20 measurements of weight of the patient, which might be reasonable if the patient happens to be an infant, the measurements might be every few weeks from birth for say 18 months. The data of each of those 20 measurements (Observations inside distinct Compositions) knows that such and such an archetype and template was used to create the data. So if the application retrieves one of the older measurements, the kernel will know which archetypes and template to apply, However, this would not occur unless someone was correcting wrongly entered values; normally previous data are just viewed, e.g. in a graph or similar, which doesn't require the kernel, just archetype-aware display components. Yes, I knew that. There seems to be some options when archetypes need to reference the same kind of information to be entered in an EHR, e.g. slots, specialisations, etc. Some EHR data should probably be limited to be created in only one archetype if it's concerning the same finding context in a domain. In addition, if data spreads over several areas of findings, single nodes from archetypes should probably not be reused and instead they should exist in several archetypes since finding procedures may change in certain domains and make the originally referenced nodes incompatible. Regards, Mattias There is also a question of whether certain data could be compatible with more than one template or archetype. It can certainly be compatible with more than one template, since templates re-use archetypes. It can also be used with parents of specialised archetypes. We have already tested ,more generic archetypes (and no archetypes) being used with data archetyped with specific specialised archetypes, and it works fine for display. does this help? - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061113/7114dfd2/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype questions
2006/11/13, Thomas Beale Thomas.Beale at oceaninformatics.biz: Mattias Forss wrote: Yes, I knew that. There seems to be some options when archetypes need to reference the same kind of information to be entered in an EHR, e.g . slots, specialisations, etc. Some EHR data should probably be limited to be created in only one archetype if it's concerning the same finding context in a domain. In addition, if data spreads over several areas of findings, single nodes from archetypes should probably not be reused and instead they should exist in several archetypes since finding procedures may change in certain domains and make the originally referenced nodes incompatible. this is our experience so far, and we have to learn (as technical people) to really trust the experience of clinical people, not think we know too much about real archetypes. The vision of archetypes is really about empowering domain users, and sometimes it can feel odd to be told we engineers don't quite know what we are talking about. I see it as a sign of a successful future for information systems development. I totally agree with this. Mattias - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061113/01487297/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML archetypes
Hi, I am doing some experiments on a XML serializer for the Java archetype editor. I wonder if there are any example XML archetypes that I can look at to verify that I follow the XML-schema documentation correctly? Regards, Mattias -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061113/26b1c469/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype questions
Hi Thomas, Thank you very much for your answers. They were quite clear and easy to understand as they often are. I have some more questions below... 2006/11/7, Thomas Beale Thomas.Beale at oceaninformatics.biz: I'll just provide some formal answers below. Mattias Forss wrote: Hi, I'm currently working in a group that has been evaluating archetypes and they found out that there in archetypes may be needed to add external nodes from other archetypes instead of only adding complete archetypes as slots. Does the current ADL specification allow that external parts from other archetypes can be included? I think the openEHR templates allow to cut off parts in a slot, but I'm not sure if they can exclude everything except a single item. - by the use of slots, which you already know about. Use this when you want to define reusable semantic units (i.e. more archetypes). Archetypes and slots can be defined at any level - including at low levels. However, the downside is potentially too many little archetypes for effective management and governance Yes, too many small archetypes would probably make the archetypes hard to maintain etc. - in some cases, most likely what is really needed is to be able to reduce the work required to build archetypes in the authoring tool environment - in other words cut and paste, or smarter things than that. So - what is smarter than cut and paste? We can consider that there are archetype fragments which are stored and indexed in a sophisticated authoring environment. These would not be separate archetypes as such - just pieces of archetypes that have been identified as re-usable in the authoring environment, but otherwise not sensible self-standing semantic units. Think about it this way - in some cases, you are not after another archetype, you just want to make sure that you build the little piece of the current archetype inn the same way as you did last time, without missing a term. Agree, but shouldn't there be some way to link the copies with each other, because they _will not_ be the same data if they don't have the same archetype path? How should we know if we already entered similar values in another archetype, possibly even found in another template than the current one? There should be some way of linking values together. Can it be done at the template level or must it be done at an even higher level, i.e. in business logic of the GUI in the EHR system? I will probably make it possible in the Java archetype editor to copy definition nodes between different instances of the program, but that is just a start. The ideal would be to support imports of nodes found in the definition of several selected archetypes... the first exists is only needed if the systolic value node is optional; the above statement in a real archetype would not necessarily be exactly as above, but the idea is clear. HOWEVER: in clinical terms, this sort of condition may not be considered as globally applicable as the rest of the archetype - it might only apply in your hospital. In this case, the same kind of statement should be added to a template instead. Yes, this condition would of course only be added in the template since it is not a global requirement (however there may be such also), but the invariants seem to have a lot of potential and would significantly aid decision support. Another issue is about computation. For example we could want a quantifiable magnitude to be the result of two previously entered values. Is this possible to do in archetypes? Perhaps in the declaration section or the invariant section? this can also be done in the invariant section using a statement of the form: exists(/path1/value) and exists(/path2/value) implies /path3/value = /path1/value + /path2/value Though it certainly is useful, this is only to constrain the allowed value and not to compute it. Some business logic in the EHR system would have to use the invariant to compute the allowed value so that the clinician doesn't have to do that (and risk to enter the wrong value and break the data entry process if the value is invalid according to the archetype). I also noticed that archetypes may become ambiguous by using invariants. For example if the cADL says that the value must be 10 and the invariant says that the value is 5. I guess there is a need for an archetype validator that checks all kinds of things, conformance to RM class names and attributes, existing codes in the ontology section, invariants conforming to cADL, etc, etc. Another feature is value reporting, which should work when we use several archetypes in an openEHR template. For example if some question was answered in one archetype, then another archetype that has the same question should get the value reported from the previous archetype. Is this possible? I guess this has to do with external references as I mentioned in my
Archetype questions
2006/11/8, Mattias Forss mattias.forss at gmail.com: We would also like to ask if there is a way of specifying validity for questions depending on previously answered questions. E.g. if a certain answer was given from a multiple alternative question (coded_text), then and only then, some other group of questions will be valid. Is this possible to do in archetypes? Perhaps it's possible with invariants? same general form as the first one, where the exists() quantifier can be used with operators like implies to state the required conditions. Does this mean that the invariant allows something like path/to/coded_text/defining_code = at0003 implies /some/path[at] occurrences.min = 1 can be used for the group of questions (cluster) we want to be valid? Oops, I meant it probably should be something like: invariant exists(/some/path[at]) implies path/to/coded_text/defining_code = at0003 //Mattias -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061108/d2cddeb8/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype questions
2006/11/6, Sam Heard sam.heard at oceaninformatics.biz: Hi Mattias I'm currently working in a group that has been evaluating archetypes and they found out that there in archetypes may be needed to add external nodes from other archetypes instead of only adding complete archetypes as slots. Not sure what you mean = only parts of archetypes e,g, Hb only from Blood count? Hi Sam, I will provide you with some examples from one of the group members. Reusing nodes: It would be reusing single nodes from archetypes, as your example above, and here are two more examples. Example 1. If the blood pressure measurement archetype allowed recording average 12h blood pressure (protocol) it would be important to be able to record the arousal state of the patient during the measurements (awake or asleep). This node (state of arousal: awake / asleep) would also be useful in an archetype for electroencephalographic results, and hence one could want to reuse it. Example 2. If there is a blood pressure measurement observation archetype without the current treatment in the patients state, there must be another observation archetype to record the current treatment, because this information is mandatory to interpret blood pressure results. In this current treatment archetype, one could wish to record the pharmacological class of each hypertensive drug (quite long list). This list could be reused in a treatment history evaluation archetype, that would record when every drug has been started and stopped and why. Is it possible, by one way or another, to reuse a single node defined in a first archetype when building another archetype? when building a template? Does the current ADL specification allow that external parts from other archetypes can be included? This is done in templates at present = need some examples So I need to know if we could remove everything but a single node (ELEMENT) from for example an OBSERVATION slot. I think the openEHR templates allow to cut off parts in a slot, but I'm not sure if they can exclude everything except a single item. You can exclude all archetypes - again need more specificity! Vide supra The group also found out that there is a need to deduct certain answers depending on previously answered questions. For example if we previously answered that the blood pressure was above 160, then another question about hypertension should be answered automatically. Is this possible to do in archetypes? I think this is application space - I do not think you can express this in an archetype...probably better if there is more detail. Example: If the blood creatine value is included an archetype, it could be useful to state that if the result is more than a given upper value, then the default value to the following boolean node renal failure has to be yes. It might be that this always is in application space and probably a task of a template builder (user-interface business logic building). Another feature is value reporting, which should work when we use several archetypes in an openEHR template. For example if some question was answered in one archetype, then another archetype that has the same question should get the value reported from the previous archetype. Is this possible? I guess this has to do with external references as I mentioned in my first question. Again difficult to know what you mean = sounds like application space though. Example: In an observation archetype having the body weight as one of its nodes, it could be useful to state that the default value for this node is the last previously entered value through this same archetype or even through another archetype. The latter might be easier to achieve in the runtime system if there could be some way of having external references (pointers) but archetypes could more easily be broken if they reference non-existing items. Anyway, this shall be dealt with on the user-interface level. For example, values could be linked together by some value map that has the related archetype paths that share values which allows the user-interface to know if values have been previously added (and when). We would also like to ask if there is a way of specifying validity for questions depending on previously answered questions. E.g. if a certain answer was given from a multiple alternative question (coded_text), then and only then, some other group of questions will be valid. Is this possible to do in archetypes? Perhaps it's possible with invariants? Perhaps = but we see this as application space unless it is an absolute fact - then it the other values could become mandatory based on the value of another value. Example: It could be useful to state that the cluster node smoking habits is not valid (and not displayed to the user) if the value of the node (which doesn't neccessarily have to reside within the cluster) current smoker is No. Again, this can probably be considered as application space, but
[Norton AntiSpam] Re: Archetype questions
2006/11/3, ognian.pishev at oceaninformatics.biz ognian.pishev at oceaninformatics.biz: I believe that in answering this series of questions one has to distinguish among: 1. what archetypes do - they define valid data based on the constraints of a clinical concept model; 2. what needs to be done by decision support systems that rely on archetypes, that is, to make sense of results recorded using archetypes; and 3. what a template builder can do using archetypes to introduce business logic and dependenices into the template one needs for specific purposes. As you can see, archetypes do not address all the issues listed in 1-3. Hi Ognian, These are exactly the points I have tried to explain to the group I am working with, I just needed to verify them on this list since there are more experienced people here. The group have been comparing templates, in their sense meaning archetypes from openEHR and templates based on the HL7 RIM, but they are hard to compare since not archetypes alone can address all issues. Many of the points the group has come up with in their evaluation are in openEHRs case more about what a template builder can do, rather than what an archetype editor can do. There were also many requirements on doing computations and decision support like things in archetypes. I find that there may exist some basic computation and DSS in archetypes but it is part of RD as Gerard pointed out. Regards, Mattias Ogi Pishev P.S. As for the ...v3 stuff, I'd like to see computing systems that machine process those... (And I don't mean Excel). Quoting Williamtfgoossen at cs.com: Mattias Forss mattias.forss at gmail.com wrote: Hello Mattias, these are exactly the questions, issues I have been working on for 3 years now. All I can specify in the HL7 v3 Care Provion Domain model, that is basically why I apply this method for the time being, waiting for a better tool to do this. Below specific answers after each question. Hi, I'm currently working in a group that has been evaluating archetypes and they found out that there in archetypes may be needed to add external nodes from other archetypes instead of only adding complete archetypes as slots. I agree, in the care provision we therefore have included the organizer class that allows you to start with atomic items, link them via an organiser code to a higher level item (e.g. blood pressure is part of vital signs, mobility is part of activities of daily living, potasium is part of electrolytes etc.). I work bottom up because of another question of you below. This is possible in ADL I believe / am told, but have not seen operationalised yet. However the template specifier does this, but I am not sure how the formal links work. In organiser we can code the higher level rubrics. Does the current ADL specification allow that external parts from other archetypes can be included? I think the openEHR templates allow to cut off parts in a slot, but I'm not sure if they can exclude everything except a single item. We break down such care information models in two parts if there are use cases where only a part is used. So we make 2 slots instead of one. The group also found out that there is a need to deduct certain answers depending on previously answered questions. For example if we previously answered that the blood pressure was above 160, then another question about hypertension should be answered automatically. Is this possible to do in archetypes? We can relate HL7 obs classes to each other, including if a value of Obs 1 160, then Obs gets default hypertension. However, there is no agreed formalism in HL7 v3 to do this. Arden syntax an d Gello are often named in this area, but I have no examples. I just use plain english for the time being. Another issue is about computation. For example we could want a quantifiable magnitude to be the result of two previously entered values. Is this possible to do in archetypes? We apply this a lot in the HL v3 care information models. Basically most scales have a kind of sum up feature of say 10 observations (Barthel) each gets a numeric score and obs 11 is for the total score. In the method section we define: total score, but again, there is no formalism used, just plain English. Similarly this would work with basic calculations such as average scores, or the formula for the body mass index etc. Perhaps in the declaration section or the invariant section? I've seen that these sections should contain some kind of first-order predicate logic, but I'm not sure of the scope and limitations/possibilities of these ADL sections. Also, the declaration section is actually not even described in the ADL 1.4 document, it is only shown in an example overview figure. It is perfectly possible to express your rules in predicate logic and if only
Archetype questions
Hi, I'm currently working in a group that has been evaluating archetypes and they found out that there in archetypes may be needed to add external nodes from other archetypes instead of only adding complete archetypes as slots. Does the current ADL specification allow that external parts from other archetypes can be included? I think the openEHR templates allow to cut off parts in a slot, but I'm not sure if they can exclude everything except a single item. The group also found out that there is a need to deduct certain answers depending on previously answered questions. For example if we previously answered that the blood pressure was above 160, then another question about hypertension should be answered automatically. Is this possible to do in archetypes? Another issue is about computation. For example we could want a quantifiable magnitude to be the result of two previously entered values. Is this possible to do in archetypes? Perhaps in the declaration section or the invariant section? I've seen that these sections should contain some kind of first-order predicate logic, but I'm not sure of the scope and limitations/possibilities of these ADL sections. Also, the declaration section is actually not even described in the ADL 1.4 document, it is only shown in an example overview figure. Another feature is value reporting, which should work when we use several archetypes in an openEHR template. For example if some question was answered in one archetype, then another archetype that has the same question should get the value reported from the previous archetype. Is this possible? I guess this has to do with external references as I mentioned in my first question. We would also like to ask if there is a way of specifying validity for questions depending on previously answered questions. E.g. if a certain answer was given from a multiple alternative question (coded_text), then and only then, some other group of questions will be valid. Is this possible to do in archetypes? Perhaps it's possible with invariants? Finally is there a way of specifying the relevance of answers in archetypes. Say for example that if some laboratory results are too old, could an archetype contain some restrictions that make it illegal to answer certain questions because the material that the answers are based upon is too old? I'm not sure if this is related to DSS or something else. Regards, Mattias, via the Link?ping Team. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061103/4f968b4d/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
ISM_TRANSITION
Hi again,
I should probably also mention that we need some document that provides
recommendations about how archetypes should be created when there are more
than one way to do it like the example below. Otherwise there is a risk that
there are too many archetypes with different representations that
essentially mean the same thing.
The rules that Thomas talked about in this thread
http://www.openehr.org/advice/implementers-priv/msg00311.html , i.e.
- if there is a plug-in C_DOMAIN_TYPE type available, always use it to
represent constraints for the corresponding RM type
- if there is a syntax equivalent for this type, then use it
- otherwise use generic ADL
Should also be documented somewhere.
Regards,
Mattias
2006/10/31, Mattias Forss mattias.forss at gmail.com:
Hi,
I started wondering about different representations of ISM_TRANSITIONs of
the ism_transition attribute in the ACTION archetypes. I found that the
below example:
ISM_TRANSITION matches {
current_state matches {
CODED_TEXT matches {
code matches {[openehr::524]}
}
}
careflow_step matches {
CODED_TEXT matches {
code matches {[local::at0001]}-- Planned
}
}
}
ISM_TRANSITION matches {
current_state matches {
CODED_TEXT matches {
code matches {[openehr::524]}
}
}
careflow_step matches {
CODED_TEXT matches {
code matches {[local::at0004]}-- Requested
}
}
}
could be compressed into this:
ISM_TRANSITION matches {
current_state matches {
CODED_TEXT matches {
code matches {[openehr::524]}
}
}
careflow_step matches {
CODED_TEXT matches {
code matches {[local::at0001, -- Planned
at0004]} --
Requested
}
}
}
The examples have the same semantic meaning. However, at data entry the
second example would mean that a choice must be made concerning the
careflow_step, i.e. either at0001 or at0004. Should the archetype editors
support both examples? The first example is the only one I've seen in
archetypes...
Regards,
Mattias
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061031/acd0c4b4/attachment.html
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
a zero existence constraint
How about specialised archetypes? Wouldn't there be occasions when a
parent archetype has some attribute, which a child (specialisation) of
that archetype don't want to deal with?
Mattias
2006/10/25, Sam Heard sam.heard at oceaninformatics.biz:
This is not sensible to have in an archetype - otherwise it would not be
there! It is a requirement for templates in use.
Sam
Thomas Beale wrote:
Andrew Patterson wrote:
For the case where an attribute is constrained to '0'
existence i.e.
state existence matches {0} .
what should follow as the rest of the attribute
constraint? Technically, the rest of the definition
is superfluous as we have already stated that the
attribute must not exist, but the
'matches' clause needs to exist in the grammar. Should
it be matched to *, or should it be empty?
state existence matches {0} matches {*}
or
state existence matches {0} matches {}
(I'm not sure the grammar allows this)
we certainly have not allowed for it yet; indeed, no-one has ever wanted
to do it in an archetype, it has only come up as a need in templates
(which simply quote path names and then add an existence constraint).
Possible responses that come to mind:
- in openEHR we try never to include a feature that is not justified by
at least one known use case. So we should try to find a real use case
before doing anything.
- there is in fact already a way to do this: by adding an invariant to
an archetype of the form
not exists (/path/to/some/attribute/that/we/dont/want)
- if we had to add more syntax to the cADL part of ADL, I would probably
opt for the second proposal above.
Buta credible use case needs to be found first.
- thomas beale
Andrew
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Dr. Sam Heard
MBBS, FRACGP, MRCGP, DRCOG, FACHI
CEO and Clinical Director
Ocean Informatics Pty. Ltd.
Adjunct Professor, Health Informatics, Central Queensland University
Senior Visiting Research Fellow, CHIME, University College London
Chair, Standards Australia, EHR Working Group (IT14-9-2)
Ph: +61 (0)4 1783 8808
Fx: +61 (0)8 8948 0215
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype blood_pressure: Data - State - Protocol - correlation
2006/10/11, Thomas Beale Thomas.Beale at oceaninformatics.biz: Mattias Forss wrote: 2006/10/9, Mattias Forss mattias.forss at gmail.com: 2006/10/8, Sam Heard sam.heard at oceaninformatics.biz: Christoph Some things have been around for a long time in our development and one was to have state defined at the root level even though it applied to each event. The current editor should read both but saves the correct version. The result is attached, Sam I should point out that the embedded state within each event isn't supported by the Java Archetype Editor (only separate state with history), but a new version that supports this will probably be out soon... Actually, when the Java editor finds a state defined at the root level it is transformed to a state with history because that is the closest thing it resembles. Another question related to this. Is there any need in an archetype editor to specify different data and state for some events instead of always creating them in the first event in the history and then let all the succeding events reference (use_node) the data and state in the first event? If a user decides to edit ADL manually and sets different data and state for some events, it is not supported by neither of the current archetype editors... In general this should not happen, since the phenomenon being recorded in each event is supposed to be the same one, just at different time-points. Just what I suspected. Thanks Mattias - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype blood_pressure: Data - State - Protocol - correlation
2006/10/8, Sam Heard sam.heard at oceaninformatics.biz: Christoph Some things have been around for a long time in our development and one was to have state defined at the root level even though it applied to each event. The current editor should read both but saves the correct version. The result is attached, Sam I should point out that the embedded state within each event isn't supported by the Java Archetype Editor (only separate state with history), but a new version that supports this will probably be out soon... Actually, when the Java editor finds a state defined at the root level it is transformed to a state with history because that is the closest thing it resembles. /Mattias ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype blood_pressure: Data - State - Protocol - correlation
2006/10/9, Mattias Forss mattias.forss at gmail.com: 2006/10/8, Sam Heard sam.heard at oceaninformatics.biz: Christoph Some things have been around for a long time in our development and one was to have state defined at the root level even though it applied to each event. The current editor should read both but saves the correct version. The result is attached, Sam I should point out that the embedded state within each event isn't supported by the Java Archetype Editor (only separate state with history), but a new version that supports this will probably be out soon... Actually, when the Java editor finds a state defined at the root level it is transformed to a state with history because that is the closest thing it resembles. Another question related to this. Is there any need in an archetype editor to specify different data and state for some events instead of always creating them in the first event in the history and then let all the succeding events reference (use_node) the data and state in the first event? If a user decides to edit ADL manually and sets different data and state for some events, it is not supported by neither of the current archetype editors... /Mattias ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Release of Java Archetype Editor v0.4
Dear all, The Java Archetype Editor v0.4 has now been released. Both the binary and the source code is available for download here: http://www.imt.liu.se/mi/ehr . Please take your time to read the release notes before installing the program. The Archetype Editor was developed within the framework of the EU-funded Network of Excellence entitled Semantic Interoperability and Data Mining in Medicine. Read more about Semantic Mining at http://www.semanticmining.org . Best regards, Mattias Forss via the Medical Informatics Group, Department of Biomedical Engineering, Link?ping University, Sweden ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
the periodic definition in data structures IM
2006/9/26, Thomas Beale Thomas.Beale at oceaninformatics.biz: I have improved the documentation in the class definitions, and added the following invariant to History: period_consistency: is_periodic implies events.for_all (e: EVENT | e.offset.to_seconds.mod(period.to_seconds) = e.offset.to_seconds/period.to_seconds) Hi Thomas, With the risk of making a fool of my self, shouldn't a consistent period mean that all events should have an offset to the original time of starting the observations which is periodic? In that case, doesn't it mean that the offset modulo the period should be zero and not offset/period? If the offset is evenly dividable with the period, then it should mean that the event is periodic and if all events are periodic then the period for the history is consistent. Correct me if I'm wrong. /Mattias and added the query to_seconds: Double to the ISO8601_DURATION class in the Support IM package. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060926/ac1e2ba5/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Normal and other ranges
2006/9/20, Gerard Freriks gfrer at luna.nl: Hi, I'm not a pathologist. But was a GP. As GP I'm not interested in an arbitrary classification. What is minimally necessary are: the value, the units of measurement and the normal range as used in that lab for that measurement at that time. What is handy (optional) and only for signalling a human reader, and NOT for computer semantic processing, are: a Flag that a value is out of range, and a comment/advice/interpretation provided by the lab. What about decision support software? /Mattias Value is not always a series of digits. It can be an ordinal. It can be text. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 20-sep-2006, at 0:27, Heath Frankel wrote: So, it appears that we have no pathologists on the list to comment on the standardisation of these codes. I guess all I can suggest is that these are standard codes as per the HL7 V2.x standard but the interpretation of using them is unlikely to be but it is just that we are looking the capture and not loose in the translation from HL7 message to openEHR. Having said that, in Australia it is common practice by labs to use three levels of abnormality (i.e. HHH LLL(. Would an alternate approach be to include an additional element in the Archetype to store this abnormality flag rather than including it in the DV_ORDERED? ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060920/49e34d63/attachment.html
Archchetype editor on Linux --help
2006/9/2, Bert Verhees bert.verhees at rosa.nl: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mattias Forss schreef: We used (and modified) parts of the code from the existing editor which was used as a facade against the openEHR archetype object model since that model is immutable. On the other hand, I don't think that this code is easy to understand even if you understand the API for the Java kernel. When we open source the code for the editor I suppose there might be questions if the facade code is worth using anymore or if it should be replaced with a better API that could be used as a facade for the archetype object model. I don't know what you mean in this, I think the best way to write a archetype editor is to directly use the java-kernel-code. I see some people want to rewrite the adl-parser, but, in fact the adl-parser is in its source quite clear and good. We cannot use the kernel code directly unless we make changes to it to be mutable (changeable). The reason for this is because whenever you want to alter things, the Archetype object has to be rebuilt all over again because it is not allowed to be changed. Using the kernel code directly and rebuilding every time some small thing has changed would be very slow (especially very slow response in the GUI). However, I've heard of a new technique that could be used in Java to be able to do this a lot faster, but I'm not sure if it will solve all the problems in this case. For me it is necessary to work also outside the reference model, but in ADL. It is a bit complicated to explain, Maybe read my previous mails. So I need a archetype-editor which loads ADL-files, and does not enforce or check the referene model. I translate HL7 XSD-files directly to ADL, that is to say, I am working on that, and the improvements give hope. The thing I miss is to viualize my ADL-files, so I have to check/debug them manually, which is hard. I could use the code of the archetype editor to change it for my needs, maybe it is not hard to do, but maybe it is, as I read about ugly code now. This would require a feature in the editor to chose an unknown reference model (which you can give a name) and maybe also specify that reference model's semantics. It could be really messy working with unknown reference models, and hard to come up good ways to display things in a GUI. Since any rm type name can really constrain any data type (text, boolean, date) even things there aren't any corresponding controls for. I have almost finished implementing an ADL-editor, (in the formats view of the archetype editor) which could be used to edit whatever the parser accepts, but whenever the ADL is reloaded in the GUI, all things not corresponding to the openEHR RM (and things that aren't recognized as editable in the GUI) will disappear. I believe you could use this ADL-editor as a start, since it marks the line number that the parser fails on, but the downside is of course that you would have to do things manually. On the other hand, I don't think it's easy to create efficient GUIs for unknown reference models, since class and attribute names always have to be specified, unless of course one creates a really smart GUI that follows defined RM semantics which configures the widgets' functionality. Regards, Mattias Except from my needs, which is at this moment, get a certain HL7 DMIM into ADL, I would think it is a good thing when a ADL-editor has a possibility for not to enforce the OpenEHR reference model. With all respect to the design of that model (clever people work hard on it. I sure want to follow that in the near future), I think it can be good if it is possible if people have good reasons to do something else with ADL, to facilitate that. So in this context, I think publishing the code will be very good. I hope it will be done in short time. regards Bert Verhees 2006/8/28, Bert Verhees bert.verhees at rosa.nl: There is already a Java-based archetype editor available here: http://svn.openehr.org/knowledge/archetypes/dev/index.html Too bad, the sourcecode still is not published (last time I downloaded it), I would like to see some improvements in (f.e.) error-handling. It does never say why I ADL-file cannot be loaded, it just says it cannot load it. There are many ADL-files, which it does not load, and I think for good reasons, but it should say why. If it had sourcecode with it, I would have repaired this, for my own use, because I have need for an Archetype-editor which can also be used for debugging purposes. The source code will be published as open source in the future, but we at Link?ping university haven't decided when that will be. I think you probably know that publishing source-code in a early stage has advantages, this is specially true when one wants to publish it anyway. It allows others to implement features they need, and you can keep control
Archchetype editor on Linux --help
There is already a Java-based archetype editor available here: http://svn.openehr.org/knowledge/archetypes/dev/index.html Regards, Mattias Forss 2006/8/27, minreddy minreddy minreddy at yahoo.com: Hello I'm thinking to port Archchetype editor to Linux. (As myself don't run windows at all) Are there any other dependencies other than ADL parser? (adl_java_lib.dll) Any help will be greatly appreciated! rgds minreddy -- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1?/min. http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://messenger.yahoo.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060828/a5a888f0/attachment.html
Archchetype editor on Linux --help
. This was an obvious way to make it easier for a user to know what part of an archetype he/she is editing. In retrospect, the current GUI design is not optimal and it could have been designed in several different ways but we didn't want to compromise the usability of the program. For example if the entire archetype could be edited in a single view it could be to many things (buttons, floating toolbars, popup menus, commands, etc.) to keep in mind for the user. We have many plans for the editor and there had been discussions of adding another view in which the user can edit large parts of archetypes in a completely different manner compared to the current editing process. Probably a lot of things will happen in the future when other programmers can join an open source Java archetype editor project. Regards, Mattias These are only some suggestions from a rainy day in region of the South Central France regards Bert Verhees Regards, Mattias Forss 2006/8/27, minreddy minreddy minreddy at yahoo.com: Hello I'm thinking to port Archchetype editor to Linux. (As myself don't run windows at all) Are there any other dependencies other than ADL parser? (adl_java_lib.dll) Any help will be greatly appreciated! rgds minreddy -- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1?/min. http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://messenger.yahoo.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060828/bd6ed46b/attachment.html
OBSERVATION.state attribute
Hi all, I have found out that the observation archetypes at the openEHR archetype repository are not following the specifications for the attribute OBSERVATION.state. This attribute is supposed to be a HISTORYITEM_STRUCTURE with existence set to optional (i.e. 0..1), but for the archetypes at the repository the state attreibute is of the type ITEM_STRUCTURE which make it equal to the CARE_ENTRY.protocol attribute. I believe all the observation archetypes that have the state attribute will have to be fixed... Regards, Mattias Forss -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060808/92bfc4fd/attachment.html
Activity class
Hello, I read that the ACTIVITY class of an INSTRUCTION is LOCATABLE meaning that it can have a runtime name, but why isn't this supported in Ocean's archetype editor? Have I missed something. I assume that since an archetype defines a model of the list of activities we cannot have several activities with different names, i.e. ACTIVITY[at0001], ACTIVITY[at0002] for the container attribute, but we should at least have the possibility of modelling runtime names for the activity, since several instances can exist in the EHR data. Any comments on this? I would also be pleased if someone also could answer my previous questions about composition attributes. Should it be possible to have several categories for a composition? Should the category attribute always be present in a composition archetype? Regards, Mattias Forss -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060807/8ea56d5e/attachment.html
Composition attributes
Hi all,
I'm currently upgrading the Java Archetype Editor (can be found at
http://www.imt.liu.se/mi/ehr) to support the newest COMPOSITION archetypes
that are available on the openEHR website. For this upgrade I have come upon
a question about some attributes.
The attributes I'm wondering about are the ones that have occurrences 1..1,
meaning they are mandatory. Here I'm interested in the attributes
COMPOSITION.composer and COMPOSITION.category. The composer attribute is of
the type PARTY_PROXY and the category is a DV_CODED_TEXT. Now to my
questions.
Should COMPOSITION archetypes always contain these attributes, e.g. with at
least a line the_attribute matches {*} in the ADL or can these mandatory
attributes be discarded completely in the archetypes? Actually this question
goes for ENTRY subclass archetypes as well, because the
ENTRY.subjectattribute is also mandatory.
If mandatory attributes always should be present in archetypes, it would
mean that attributes such as COMPOSITION.territory also would be modeled but
I believe some of the mandatory attributes aren't supposed to be put in
archetypes as of yet. At least I haven't found this attribute in any
archetypes at the openEHR website.
The reason for this question is actually because I saw that the category
attribute is only modeled with one category code at a time in Ocean's
archetype editor. I think that the attribute could be modeled with several
category codes to chose from when creating the EHR content. I'm not sure if
it's good in a user perspective, but I don't see a reason why it shouldn't
be possible. Any comments?
Regards,
Mattias Forss
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060804/b3c8ecd2/attachment.html
About the Archetype lifecycle state
Hi David, The lifecycle field is optional in the archetype identifier, see http://svn.openehr.org/specification/TRUNK/publishing/architecture/am/archetype_system.pdf . However, this document is under re-development so I don't know more about the identifier than what's in the document. Another thing worth mentioning is that the Support terminology document is not in line with Ocean's editor and that is why they have more life cycle states than specified. This probably depends on shortage of specified states, so I guess Ocean just added a couple of their own. The computable Support Terminology in XML format should be updated to follow the specifications... Regards, Mattias 2006/6/16, David Moner damoca at gmail.com: Hello everybody, I have a question about the archetype lifecycle state. This may not be a fundamental question, but it is important to formalize all the aspects regarding to an archetype system. This is what I have found about this topic reading through all the documentation. First, at the ADL2 document, the section related to the Archetype Identifier references to the Archetype System document. There we can find a clear description of the Multiaxial Archetype Identifier. Well, clear except the life_cycle field. Reading the provided examples we get two possible values: * draft * in_test Looking for a more formal definition I read the Version Lifecycle State section at the Support Terminology document. Although it seems that is referred to another question (the revision of an archetype item), it is the only mention to the lifecycle in the entire document. This is what appears there. * complete: Item is complete at time of committal. * incomplete: Item is incomplete at time of committal, in the view of the author. Further editing or review needed before its status is set to finished. * deleted: Item has been logically deleted. * draft: DEPRECATED. * active: DEPRECATED. * inactive: DEPRECATED. * awaiting approval: DEPRECATED. Finally, for my surprise, it is the case of the Ocean Archetype Editor (Version 0.99.5c Alpha). We can define with it something called Authorship lifecycle with these possible values: * Not set(en) * Initial(en) * Author draft(en) * Author draft(en) * Committee draft(en) * Organisation draft(en) * Submitted(en) * Candidate(en) * Approved candidate(en) * Published(en) * Rejected(en) * Obsolete(en) Furthermore, these values are recorded at the description.lifecycle_statefield of the ADL but make no change at the archetype identifier (maybe a bug?). This is the situation that I have found when studying in depth such a simple thing as the lifecycle state of an archetype. As I said at the beginning, this may not seem a fundamental problem at this stage of development, but it should be revised in order to get a more coherent archetype system and really useful archetype repositories (to assure that the archetype that they contain are reliable). This takes me to a more interesting question. Is it defined any policy for archetype management related to their lifecycle state? I haven't found anything about this topic. For example, this could be a very simple policy. * initial: The archetype is still in an embryonic stage. It makes no sense to validate it because its definition is not finished. * draft: Syntactically correct (from a direct ADL editing point of view or just with all the definition tree finished), but not semantically correct according to the reference model or its parent archetype (that is, the archetype doesn't respect the reference model or parent archetype constraints). It may also lack of terminology bindings. * test: Syntactically and semantically correct in the terms stated before. State for testing whether the EHR extracts based on it are what we want or need. In other words, at this state we are testing if the archetype fulfils the clinical concept that it is being defined. * final: Only an archetype in its final state should be stored at a public archetype repository. It is a valid archetype approved by a commission of experts and its ready to be used by any institution. This would be an interesting point for a deeper study. -- David Moner Cano ITACA - BET - Grupo de Inform?tica Biom?dica http://gim.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso 3, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060619/f3562b13/attachment.html
Specification of ITEM_TABLE
2006/5/17, Thomas Beale Thomas.Beale at oceaninformatics.biz: Sam Heard wrote: Mattias This is a good discussion with some issues that need to be taken further. The problem I face as a clinician is that tables in medicine are often presented with the same data types across the row - and with the values in the first column as column headings. This is a standard pivot table in Excel or Access and is a common data presentation issue - which SQL can perform. I don't have a problem with the rotate idea - if clinical people want it and it makes sense, then it is needed. But - most likely need add an attribute to the reference model. Here's the problem if we don't: - archetypes only constraint data that is created - whether a table is rotated or not becomes important at display / interpretation time of the _data_, not the archetype. - so any mention of the rotate attribute in the archetype must lead to some flag being set in the data in order to get the behaviour at runtime The only way out of this is that we take the line that the archetype must always be available at the time the data are used, in whatever circumstance. Technically it isn't hard to engineer this in nice controlled OO environments, but consider that the data might be processed into various kinds of good-quality or not-so-good quality XML, HTML, PDF, other custom formats, where the corresponding archetypes might not be easily available or needed. I would guess that many applications should be able to process e.g. path results as openEHR structures without needing to look up the archetype. So my conclusion is that we should always ensure that the data can stand alone and remain meanggul. I cannot agree more with that, so the best thing to do is probably to include the attribute into the RM class if there is a need for a rotated attribute. However, at this point I don't see that there is a huge need for it since the data could always be presented in a pivot table but then some might disagree with me, I'm not the clinician here. Now - in the case of reflexes, visual acuity and other tabular data, one (presumably) could argue that the data are perfectly comprehensible even with no 'is_rotated flag set; others might argue the opposite. I personally don't see a problem with including a flag in the RM ITEM_TABLE class, but we need to do it now. I do not believe it is possible to determine from data alone when it is appropriate to rotate a table for presentation. This is why I have pushed to have it in the editor. I think a lot of clinicians will find it difficult to accept information in unrotated form as it is not how they do it now for many situations. There are many situations where this is not the case as well. I agree that the right thing to do is put this in ADL if we want to - we could just say we leave it to the display - but I think this will mean clinicians find it hard to build the tables they need. We can experiment some more with this as it is an ADL issue rather than a reference model issue. I would suggest that you ignore it if you like for the moment (with the result of frustrating the clinicians) or take the attribute as it is and agree to put it into ADL. do you mean the reference model Sam - it can't be put into ADL unless we create a C_ITEM_TABLE type, which I don't think we should have to do There should probably be enough to use the attribute in the ITEM_TABLE. What I don't see at this point is if the most common way to display table data is pivot tables, then will there ever be cases when the data must explicitly be shown in an unrotated form? But what about the other problem Mattias pointed out - we don't have an attribute key-columns in ITEM_TABLE either. Previously we specified that if there was a (key) in the name string of a column, it would be a key column, but this is open to abuse by buggy software. The alternative is to add another attribute into ITEM_TABLE that contains a list of key column indexes or names. But I would like to be sure that this feature is really needed in table archetypes...is it? If one thinks about an ordinary SQL query to some database that contains an inventory of for example some equipment, then there might occur several records of the same name and therefore these must be separately identifiable with unique keys in order to get the specific equipment from the database. Then what options are there in ADL? If we know that an ITEM_TABLE always has some column that is uniqe then that should be mentioned as the key so that the process of creating the RM data will not allow creation of data that don't have uniqe identifiers. It might even be the case that there have to exist several keys but not as long as there isn't a need for column headers with the same name. Regards, Mattias - thomas -- ___ CTO Ocean Informatics
Specification of ITEM_TABLE
2006/5/16, Sam Heard sam.heard at oceaninformatics.biz:
Mattias
I looked at this document
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/data_structures_im.pdf
and it says that ITEM_TABLE.columns attribute has been changed to rows in
the amendment record (CR-000207). However, the change hasn't actually been
commited in the document, so maybe the change was lost somehow...
rotated is an archetype only attribute which allows rotated tables to be
displayed - this is like a pivot table in Excel.
Is this attribute documented somewhere? I don't really understand why this
attribute is allowed under ITEM_TABLE when it is not specified for the
actual data structure.
If a table is rotated it means that the values in one column become
columns headings, with the columns becoming rows. E.g.
Reflexes:
laterality knee ankle
left ++ +/-
right ++
When this is rotated it becomes:
left right
knee ++ +
ankle +/-+
This is called a pivot table and allows rows of the same data type rather
than columns which is the usual. This is more than display although the
semantics are not effected. Infact, all tables in the editor are rotated at
the moment as this is by far the most common way of presenting data in
medicine.
Thanks for your answer Sam,
I have another question about this rotated attribute. Why do we need it when
it is only a question of how to display the actual data contents? Shouldn't
that be decided by an actual user rather than an attribute? I don't think
the ADL contents and underlying structure of an ITEM_TABLE should change
even if it were possible to switch between pivot tables and ordinary tables.
Now to the important question that I'd been thinking about. The
specifications of ITEM_TABLE say that the rows attribute should have a
ListCLUSTER as children but I don't see the point with this. Why do we
need several clusters as rows since a table with rows that each have
different column headings is impossible to create? If the rows attribute had
ListITEM as children it would make much more sense. Also, It wouldn't be a
bad idea to have rows and column headings as separate attributes instead of
having the column headings of the table in the first element under the rows
attribute.
By the way, I don't think it's usable to show the table data types as
columns since that would probably only confuse the user compared to how tree
and list are displayed. So for this part I agree with you.
Number of key columns is in the new specifications.
This allows unique keys and means that the values of the combined keys
have to be unique - if this is not set then there is no restriction on
uniqueness.
Why is this attribute's leaf value an integer? I don't understand this part.
Does this mean that if the user creates two rows with the same name, for
example knee then the uniqueness wouldn't be preserved and then another
key column would have to be added... Maybe the table should always have an
extra column that contain unique keys (as for the ordinal constraint).
Hoping for a quick answer.
Cheers,
Mattias
This attribute is also missing in the document I mentioned above. By the
way, could you explain this attribute to me? Should the users of an
archetype editor be able to change the existence and/or contents of this
attribute with some GUI component or should it be done automatically
whenever new columns are added that contain actual data (ELEMENTs)?
Tom will be getting to this I think as I did an edit some time ago..Sam
Cheers,
Mattias
Hope this is OK.
Cheers, Sam
Mattias Forss wrote:
Hello,
I'm trying to add support for ITEM_TABLE in the Java Archetype Editor
and I have looked at the only archetype I've found that contains a data
structure like this. It is
openEHR-EHR-OBSERVATION.tendon_babinski_reflexes.v1.adl and it can be
found here http://oceaninformatics.biz/archetypes/. When I compared the
attributes for the ITEM_TABLE in the data structures specifications (found
here
http://svn.openehr.org/specification/TRUNK/publishing/architecture/rm/data_structures_im.pdf
) with the ones that existed in the archetype I saw that the attributes
had nothing in common. Maybe someone can explain to me how the ITEM_TABLE
look like once and for all :-)
The archetype looks like this:
ITEM_TABLE[at0003] matches { -- structure
COMMENT: The attributes below adhere to the ITEM_TABLE that you get
when you create a table structure in the Ocean Archetype Editor, but I
haven't seen any of these three attributes specified anywhere. I would be
glad if anyone could point them out to me.
rotated matches {True}
number_key_columns matches {|1|}
rows cardinality matches {0..1; unordered} matches {
CLUSTER[at0050
Specification of ITEM_TABLE
2006/5/16, Sam Heard sam.heard at oceaninformatics.biz: Mattias Quick response.. If a table is rotated it means that the values in one column become columns headings, with the columns becoming rows. E.g. Reflexes: laterality knee ankle left ++ +/- right ++ When this is rotated it becomes: left right knee ++ + ankle +/-+ This is called a pivot table and allows rows of the same data type rather than columns which is the usual. This is more than display although the semantics are not effected. Infact, all tables in the editor are rotated at the moment as this is by far the most common way of presenting data in medicine. Thanks for your answer Sam, I have another question about this rotated attribute. Why do we need it when it is only a question of how to display the actual data contents? Well, we do not think it is only a matter of display - although it could be seen as such. If the attribute is not present then it is not possible to determine whether to display it as a pivot or not. The property of DV_QUANTITY is only in the archetype as well and determines valid units - it is a similar sort of issue. Hi again Sam, I wouldn't mind to ignore and not save this attribute until the different display modes are supported in the Java archetype editor. A missing rotated attribute should probably not cause errors for the Ocean archetype editor? Now to the important question that I'd been thinking about. The specifications of ITEM_TABLE say that the rows attribute should have a ListCLUSTER as children but I don't see the point with this. Why do we need several clusters as rows since a table with rows that each have different column headings is impossible to create? If the rows attribute had ListITEM as children it would make much more sense. Also, It wouldn't be a bad idea to have rows and column headings as separate attributes instead of having the column headings of the table in the first element under the rows attribute. Well, each row is a set of elements (as a cluster) - the table is a special case in that each cluster can only have elements (invariant). Each row is a cluster - which is in effect the definition of each column. So you need a list of clusters to get rows. So then I guess the ADL is constructed according to how the first table looks like in your example above (since pivot should not affect the structure)? In that case I believe that the ITEM_TABLEs that are created by the Ocean editor aren't following the specifications, since no matter how many rows (e.g. left, right) you add, they will only be contained within one cluster only. There is accordingly no way to create an ITEM_TABLE that has more than one cluster under the rows attribute. Furthermore, each row that is added should create a cluster that has an at-code with its name and in the pivot display mode the clusters names will be the column headings. Right? Hope we can sort this out. Regards, Mattias PS. You forgot my question about key columns. See below. By the way, I don't think it's usable to show the table data types as columns since that would probably only confuse the user compared to how tree and list are displayed. So for this part I agree with you. We can take this a lot further with time and more power in the archetype editor. Cheers, Sam Number of key columns is in the new specifications. This allows unique keys and means that the values of the combined keys have to be unique - if this is not set then there is no restriction on uniqueness. Why is this attribute's leaf value an integer? I don't understand this part. Does this mean that if the user creates two rows with the same name, for example knee then the uniqueness wouldn't be preserved and then another key column would have to be added... Maybe the table should always have an extra column that contain unique keys (as for the ordinal constraint). Hoping for a quick answer. Cheers, Mattias This attribute is also missing in the document I mentioned above. By the way, could you explain this attribute to me? Should the users of an archetype editor be able to change the existence and/or contents of this attribute with some GUI component or should it be done automatically whenever new columns are added that contain actual data (ELEMENTs)? Tom will be getting to this I think as I did an edit some time ago..Sam Cheers, Mattias Hope this is OK. Cheers, Sam Mattias Forss wrote: Hello, I'm trying to add support for ITEM_TABLE in the Java Archetype Editor and I have looked at the only archetype I've found that contains a data structure like this. It is openEHR-EHR-OBSERVATION.tendon_babinski_reflexes.v1.adl and it can be found here http://oceaninformatics.biz
Specification of ITEM_TABLE
2006/5/16, Thomas Beale Thomas.Beale at oceaninformatics.biz: Mattias Forss wrote: 2006/5/16, Sam Heard sam.heard at oceaninformatics.biz mailto:sam.heard at oceaninformatics.biz: Well, we do not think it is only a matter of display - although it could be seen as such. If the attribute is not present then it is not possible to determine whether to display it as a pivot or not. The property of DV_QUANTITY is only in the archetype as well and determines valid units - it is a similar sort of issue. yes, but that's only because we have an explicit custom type called C_QUANTITY that supplies the property attribute in the archetype. Otherwise this would not be possible Hi again Sam, I wouldn't mind to ignore and not save this attribute until the different display modes are supported in the Java archetype editor. A missing rotated attribute should probably not cause errors for the Ocean archetype editor? This cannot work as explained above - either the attribute has to exist in the RM class or else we have to create a custom type like C_ITEM_TABLE for it. That's the general rule. Hi Tom, I agree with you. Either the rotated attribute is removed from the archetypes or added in the ITEM_TABLE or a custom type C_ITEM_TABLE. Now to the important question that I'd been thinking about. The specifications of ITEM_TABLE say that the rows attribute should have a ListCLUSTER as children but I don't see the point with this. Why do we need several clusters as rows since a table with rows that each have different column headings is impossible to create? If the rows attribute had ListITEM as children it would make much more sense. I don't understand thatthe current specification says that each row is logically a CLUSTER (of ELEMENTs). Of course there are more efficient ways to represent tables, but we have stuck to the tree structure used in CEN EN13606 - it is interoperable and simple to understand. Yes, I guess we're stuck for a while then... So you shouldn't worry that this structure could technically allow different column names on different rows, the software will not allow that. You get a bit of redundancy in using sub-optimal structures for interoperability purposes. I think we keep flipping around things here. I take it from the point of creating the actual RM data. What I think you mean is that if someone is clumsy it would be quite easy to create two rows with the same column name (not heading), e.g. Left? This is quite a flaw but as long as the software (kernel) won't allow this creation it's acceptable. So then I guess the ADL is constructed according to how the first table looks like in your example above (since pivot should not affect the structure)? In that case I believe that the ITEM_TABLEs that are created by the Ocean editor aren't following the specifications, since no matter how many rows ( e.g. left, right) you add, they will only be contained within one cluster only. There is accordingly no way to create an ITEM_TABLE that has more than one cluster under the rows attribute. In the archetype you would only have one row, since it is a model for numerous rows in the data...does that answer the question? Yes it does, but not how the column names/headings (depends what you mean if it's displayed as a pivot table or not) are modelled in archetypes, e.g. left, right for a reflexes archetype. They are modelled as the first ELEMENT in Ocean's archetypes and it contains a CODED_TEXT that constrain the headings. Is this the best way to represent headings? I don't understand the logic behind it since they can be mistaken for actual table data which comes after the first element. However, column names/headings are table data too but it's bad design to assume this comes first in order to show the table in an archetype editor. Maybe I could take a different approach than actually showing a real table in the GUI... Furthermore, each row that is added should create a cluster that has an at-code with its name and in the pivot display mode the clusters names will be the column headings. Right? this is getting mixed up between rows in an archetype (don't forget an archetype is not data, it is a model of data) and the actual data that conform to the archetype - which will of course have 1 rows in general. No I haven't forgotten about that but sometimes it's easy to think a step ahead. :-) Regards, Mattias - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060516/e546a52f/attachment.html
Specification of ITEM_TABLE
2006/5/12, Sam Heard sam.heard at oceaninformatics.biz:
Mattias
This is a mistake in the 1.0 specification and it is has been updated on
the website 1.0.1 specs. The attribute of a table is rows - each row is a
cluster of elements (it was mistakenly documented as columns).
Hi Sam,
I looked at this document
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/data_structures_im.pdfand
it says that ITEM_TABLE.columns attribute has been changed to rows in
the amendment record (CR-000207). However, the change hasn't actually been
commited in the document, so maybe the change was lost somehow...
rotated is an archetype only attribute which allows rotated tables to be
displayed - this is like a pivot table in Excel.
Is this attribute documented somewhere? I don't really understand why this
attribute is allowed under ITEM_TABLE when it is not specified for the
actual data structure.
Number of key columns is in the new specifications.
This attribute is also missing in the document I mentioned above. By the
way, could you explain this attribute to me? Should the users of an
archetype editor be able to change the existence and/or contents of this
attribute with some GUI component or should it be done automatically
whenever new columns are added that contain actual data (ELEMENTs)?
Cheers,
Mattias
Hope this is OK.
Cheers, Sam
Mattias Forss wrote:
Hello,
I'm trying to add support for ITEM_TABLE in the Java Archetype Editor and
I have looked at the only archetype I've found that contains a data
structure like this. It is
openEHR-EHR-OBSERVATION.tendon_babinski_reflexes.v1.adl and it can be
found here http://oceaninformatics.biz/archetypes/. When I compared the
attributes for the ITEM_TABLE in the data structures specifications (found
here
http://svn.openehr.org/specification/TRUNK/publishing/architecture/rm/data_structures_im.pdf)
with the ones that existed in the archetype I saw that the attributes had
nothing in common. Maybe someone can explain to me how the ITEM_TABLE look
like once and for all :-)
The archetype looks like this:
ITEM_TABLE[at0003] matches { -- structure
COMMENT: The attributes below adhere to the ITEM_TABLE that you get
when you create a table structure in the Ocean Archetype Editor, but I
haven't seen any of these three attributes specified anywhere. I would be
glad if anyone could point them out to me.
rotated matches {True}
number_key_columns matches {|1|}
rows cardinality matches {0..1; unordered} matches {
CLUSTER[at0050] occurrences matches {0..2} matches { -- row
items cardinality matches {7; ordered} matches {
COMMENT: This first element has a CODED_TEXT which contains coded
terms that are represented as columns in the Ocean Archetype Editor.
ELEMENT[at0012] occurrences matches {0..1} matches { --
row_head
value matches {
CODED_TEXT matches {
code matches {
[local::
at0011, -- Left
at0013] -- Right
}
}
}
}
COMMENT: This element and all succeding elements are represented as rows
in the Ocean Archetype Editor.
ELEMENT[at0004] occurrences matches {0..1} matches { --
Biceps
value matches {
ORDINAL matches {
value matches {
...
}
}
}
}
-
But in the specification the ITEM_TABLE it looks like this:
CLASS ITEM_TABLE
Purpose
Logical table data structure, in which columns are named and ordered. Some
columns
may be designated 'key' columns, containing key data for each row, in the
manner of relational tables. This allows row-naming, where each row
represents
a body site, a blood antigen etc. All values in a column have the same
data type.
Use Used to represent any data which is logically a table of values, such
as blood
pressure, most protocols, many blood tests etc.
MisUse Not used for time-based data, which should be represented with the
temporal
class HISTORY. The table may be empty.
Entry type.
Inherit ITEM_STRUCTURE
Attributes
0..1 columns: ListCLUSTER
Physical representation of the table
as a list of CLUSTERs, each containing
the data of one column of the
table.
Hope someone can help me.
Regards,
Mattias Forss
--
Dr. Sam Heard
MBBS, FRACGP, MRCGP, DRCOG, FACHI
CEO and Clinical Director
Ocean Informatics Pty. Ltd.
http://www.oceaninformatics.biz/Adjunct Professor, Health Informatics,
Central Queensland University
Senior Visiting Research Fellow, CHIME, University College London
Specification of ITEM_TABLE
Hello,
I'm trying to add support for ITEM_TABLE in the Java Archetype Editor and I
have looked at the only archetype I've found that contains a data structure
like this. It is openEHR-EHR-OBSERVATION.tendon_babinski_reflexes.v1.adl and
it can be found here http://oceaninformatics.biz/archetypes/. When I
compared the attributes for the ITEM_TABLE in the data structures
specifications (found here
http://svn.openehr.org/specification/TRUNK/publishing/architecture/rm/data_structures_im.pdf)
with the ones that existed in the archetype I saw that the attributes had
nothing in common. Maybe someone can explain to me how the ITEM_TABLE look
like once and for all :-)
The archetype looks like this:
ITEM_TABLE[at0003] matches { -- structure
COMMENT: The attributes below adhere to the ITEM_TABLE that you get
when you create a table structure in the Ocean Archetype Editor, but I
haven't seen any of these three attributes specified anywhere. I would be
glad if anyone could point them out to me.
rotated matches {True}
number_key_columns matches {|1|}
rows cardinality matches {0..1; unordered} matches {
CLUSTER[at0050] occurrences matches {0..2} matches { -- row
items cardinality matches {7; ordered} matches {
COMMENT: This first element has a CODED_TEXT which contains coded terms
that are represented as columns in the Ocean Archetype Editor.
ELEMENT[at0012] occurrences matches {0..1} matches { --
row_head
value matches {
CODED_TEXT matches {
code matches {
[local::
at0011, -- Left
at0013] -- Right
}
}
}
}
COMMENT: This element and all succeding elements are represented as rows
in the Ocean Archetype Editor.
ELEMENT[at0004] occurrences matches {0..1} matches { --
Biceps
value matches {
ORDINAL matches {
value matches {
...
}
}
}
}
-
But in the specification the ITEM_TABLE it looks like this:
CLASS ITEM_TABLE
Purpose
Logical table data structure, in which columns are named and ordered. Some
columns
may be designated 'key' columns, containing key data for each row, in the
manner of relational tables. This allows row-naming, where each row
represents
a body site, a blood antigen etc. All values in a column have the same data
type.
Use Used to represent any data which is logically a table of values, such as
blood
pressure, most protocols, many blood tests etc.
MisUse Not used for time-based data, which should be represented with the
temporal
class HISTORY. The table may be empty.
Entry type.
Inherit ITEM_STRUCTURE
Attributes
0..1 columns: ListCLUSTER
Physical representation of the table
as a list of CLUSTERs, each containing
the data of one column of the
table.
Hope someone can help me.
Regards,
Mattias Forss
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060511/d69c8b7c/attachment.html
New alpha of release 1.0 archetype editor
Hi Sam, I've been looking at the openEHR archetype profile specification and I can see that for the C_DV_QUANTITY class the property attribute should be a data type called DV_CODED_TEXT. However, I haven't seen the [terminology::code] representation of a coded text in the archetypes that are packed with the latest version of the archetype edtior on the Ocean site. Also, I haven't found a version called 1.0 that you say, the latest I could find is 0.99.5b. Instead of the [terminology::code] representation I have seen a string representation of the property e.g. pressure. I think it would be good if the properties are coded according to the openEHR support terminology ( http://svn.openehr.org/specification/TAGS/Release-1.0/publishing/architecture/computable/terminology/terminology.html) so that they become more language independent. Hope you can give me some clarity in this issue. Cheers, Mattias Hi Everyone I have posted a new exe of the release 1.0 archetype editor on the Ocean site with sample archetypes.a little more to do but it is getting very close. I would appreciate testing and comments back via the reporting menu item on the editor. Cheers, Sam -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. Ltd. http://www.oceaninformatics.biz/Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) *Ph: +61 (0)4 1783 8808* *Fx: +61 (0)8 8948 0215* -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060421/a14d0de9/attachment.html
Question about Composition archetypes
Yes they are still 0.97 archetypes, but shouldn't they contain EVENT_CONTEXT according to the old 0.9 specifications? Anyway, I'm glad that the release 1.0 archetypes are being published soon. I've had a look at some of the new COMPOSITION archetypes and they seem to follow the specifications better. Thanks, Mattias - Original Message - From: Sam Heard To: openehr-technical at openehr.org Sent: Wednesday, April 12, 2006 2:27 PM Subject: Re: Question about Composition archetypes Mattias The Ocean archetypes are still 0.97 - we have updated all of them and will have the release 1.0 tools and archetypes available very shortly. The editor, alpha, on the Ocean site will create them in the release 1.0 form. Cheers, Sam Mattias Forss wrote: Hello, I've just compared some Composition archetypes from Ocean Informatics with the specifications at openEHR.org and I have some questions. The specifications from 0.9 to 1.0 all agree about one thing for COMPOSITION classes and that is that the attribute context in the COMPOSITION class should point to a class called EVENT_CONTEXT. However, this is not the case for the archetypes I've seen so far. Instead, the context attribute in the archetypes matches subclasses of ITEM_STRUCTURE e.g. ITEM_TREE. These classes should instead be referred by an optional attribute called other_context inside the EVENT_CONTEXT class. Can anyone please explain to me why this is the case? Regards, Mattias -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. Ltd. Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) Ph: +61 (0)4 1783 8808 Fx: +61 (0)8 8948 0215 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060412/86e6edde/attachment.html
dictionary
Hi Philippe, Well I started in the domain 20 weeks ago and I didn't know anything back then (in the old days). I'm currently on my way of finishing my master's thesis, so I cannot say I have the experience to answer your questions ;-) PS. Your questions are sensible though, no offense Cheers, Mattias Hi Mattias, The more I work on medical information systems, and the less I believe that the structure is more important than the terminology. To be a little bit more accurate, my opinion is that any health information system is there to tell stories. I started in the domain 20 years ago with endoscopy reports : the story to tell was a 10 to 20 minutes medical act. Now, for many reasons (but it would be too long to explain it there), the big thing is continuity of care, and the challenge is to be able to tell someone's whole medical journey. So, how can we tell these stories (from a 10 minutes encounter to the whole life and the fighting strategies to remain as healthy as possible) ? The answer is rather simple (at least to express) : we need to make sentences. And to make sentences requires a grammar (the discourse structure) and a vocabulary (to populate the discourse structure). Is it possible to have a discourse structure that can host any terminology ? My personal answer is 'no', but maybe I try to tell more complex stories than you intend, or maybe you have a more powerful technological solution. At large, I can ask you a question : do you think that you could communicate using the english grammar and let people choose any other language's vocabulary to populate it ? You can answer that natural language is more complex that formal language, but I can say that the more complex the story you intend to tell and the closer they need to be. Regards, Philippe The important thing in openEHR archetypes is the structure of them. As long as there is a structure that is equal for both Weight and Bodyweight, it shouldn't be a problem. The allowed information model structures in archetypes is what really matters and the terms can always be bound to external terminologies to create a mutual understanding. Regards, Mattias Forss
dictionary
- Original Message - From: Bert Verhees bert.verh...@rosa.nl To: openehr-technical at openehr.org Sent: Tuesday, February 07, 2006 11:32 PM Subject: dictionary Hi, I have a question, maybe a stupid question, don't hesitate to tell me (I can handle that), as long as you give the answer with it. Today I had the opportunity to have a good look at HealthOne, a GEHR system, many on this list will know it. One thing looked smart to me. They have a kind of Dictionary with 6000 words, (also these words are possibly related to each other, that makes it an extra strong feature). The relationship between the words is not hard coded and is not stored in medical-records, so if the relationship changes, nothing breaks, even if a word from the dictionary will be deleted (which will not easily happen), nothing breaks. The advantage is that always the same word is used when storing something, f.e. Weight Maybe OpenEhr has such a feature also. or does it depend on archetypes to force the same semantics. This seems dangerous to me, because when exchanging medical information, in an other Archetype weight can be defined as another word, a synonym, f.e. Bodyweight If one has an archetype which calculates the BMI (body mass index), it could not work on another OpenEhr system that has used (some time) another archetype to store the Weight. Or am I completetely misunderstanding the issue, and is it in fact a non-issue. Please explain to me. Thanks in advance Kind regards Bert Verhees Hi Bert, I don't think this is a big issue. The important thing in openEHR archetypes is the structure of them. As long as there is a structure that is equal for both Weight and Bodyweight, it shouldn't be a problem. The allowed information model structures in archetypes is what really matters and the terms can always be bound to external terminologies to create a mutual understanding. Regards, Mattias Forss
Missing references in documentation
Hello, I cannot find the references specified in section 2.1 of this document, can anyone help me find these please? Purpose of Archetypes and Templates Archetype Definitions and Principles Rev 0.6 http://svn.openehr.org/specification/BRANCHES/Release-1.0-candidate/publishing/architecture/am/archetype_principles.pdf Content: 2 Purpose of Archetypes and Templates 2.1 Purpose of Archetypes Archetypes are created for a number of purposes (described in detail in [1] and [3]), summarised here Regards, Mattias Forss -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051129/116d3407/attachment.html
Question about Ocean's Archetype Editor
Hello,
I'm trying to figure out which reference model Ocean's achetype editor follows.
I have an example regarding the data type Quantity, see below. There seems to
be great differences depending on what reference model the archetypes follow.
Background:
I'm trying to figure out how to get the property of a quantity but this doesn't
seem to be supported by the java kernel I'm using, so I'm asking if anyone has
a good idea on how to support this in other ways.
The current problem is that the java adl parser returns a CQuantity object
whenever it recognizes the string quantity, but when it's something else,
e.g. C_QUANTITY, it returns a CComplexObject.
Idea:
I could solve this by looking up the RM type names and the attribute names to
figure out if the ComplexObject represents something that can be interpreted as
a Quantity data type. In this way I can support the various known structures of
the data type that currently exist. Any suggestions?
By the way, shouldn't the property attribute represent a CODED_TEXT object that
can be linked to a local or external terminology? This seems to be the case
according the specifications and it goes all the way back to version 0.9 that I
think the current version of the java kernel supports (partly at least). I
would really like to know what RM Ocean's archetypes follows.
Ocean Archetype Editor archetype:
C_QUANTITY
property = Acceleration
list =
[1] =
units = cm/s2
magnitude = | 0.0|
[2] =
units = ft/s2
magnitude = |= 0.0|
Ref impl java kernel archetype:
QUANTITY matches {
magnitude matches {|0.0|}
units matches {cm/s2}
}
Acode ADLParser test achetype:
REAL_QUANTITY matches {
property matches {Acceleration}
units cardinality matches {1} matches {
UNIT matches {
unit_string matches {cm/s2}
magnitude matches {| 0.0|}
}
UNIT matches {
unit_string matches {ft/s2}
magnitude matches {|= 0.0|}
}
}
}
Regards,
Mattias Forss
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051114/6a5af7f2/attachment.html
Question about Ocean's Archetype Editor
- Original Message -
From: Thomas Beale thomas.be...@oceaninformatics.biz
To: openehr-technical at openehr.org
Sent: Monday, November 14, 2005 6:15 PM
Subject: Re: Question about Ocean's Archetype Editor
Mattias Forss wrote:
Hello,
I'm trying to figure out which reference model Ocean's achetype editor
follows. I have an example regarding the data type Quantity, see below.
There seems to be great differences depending on what reference model the
archetypes follow.
I pretty sure that the reference model is the same in all cases. There is
only one definition of DV_QUANTITY in the openEHR reference model, and as
far as I know, only one assumed in archetypes.
Thank you for your answer Thomas,
I bet the reference model is the same, but do the Ocean archetype editor
fully conform to the reference model? Take a look at the ITEM_TREE class
definition for example. You will see that the correct attribute for the
physical representation of the tree will be either representation for
version 0.9 of the specifications or root for version 0.95+ of the
specifications. However, the Ocean archetype editor does not use neither of
these attributes, instead it uses items but maybe this is correct if the
editor conforms to an earlier version of the specifications than 0.9. Anyone
who knows about this?
However, it may look different. There are two ways of representing
constraints on Quantity in an archetype. One is to use the 'standard'
method of creating C_COMPLEX_OBJECTs which mimic the sructure of the
QUANTITY class; the other is to use an instance of C_QUANTITY, which is a
custom replacement type which provides a better model of the possible
constraint on QUANTITY (while still assuming the same underlying
definition of QUANTITY).
This is interesting, but I'm getting slightly confused about the naming
here. Could you explain more and tell me the difference between QUANTITY,
C_QUANTITY and C_DV_QUANTITY. It is probably a lot easier to grasp for
someone like you.
I believe the C_QUANTITY corresponds to the CQuantity (inherits from
CDomainType) class in the java reference kernel, and the parser gives me
this object if the archetype looks like Q1. Nevertheless, I'm starting to
think that this isn't right and that the parser instead should give me the
CQuantity object if the archetype looks like Q2. What do you think? By the
way, should there exist a class called Quantity in the java kernel or maybe
it is sufficient with the CComplexObject (that mimics the structure of the
QUANTITY class)?
Q1:
QUANTITY matches {
magnitude matches {|0.0|}
units matches {cm/s2}
}
Q2:
C_QUANTITY
property = Acceleration
list =
[1] =
units = cm/s2
magnitude = | 0.0|
[2] =
units = ft/s2
magnitude = |= 0.0|
Background:
I'm trying to figure out how to get the property of a quantity but this
doesn't seem to be supported by the java kernel I'm using, so I'm asking
if anyone has a good idea on how to support this in other ways.
the property attribute is defined only in the type C_QUANTITY. It provides
a convenient way to capture the constraint that you want only length or
pressure, without saying which unit. If only the property is set in the
C_QUANTITY in the archetype, then when the kernel checks to see if an
instance of DV_QUANTITY conforms to the C_QUANTITY in the archetype, it is
up to the C_QUANTITY to carry out this check in sensible way, i.e. by
determining what property the actual units measure.
I'm not getting this... as an example, do you mean that a C_QUANTITY with
its property set to length is supposed to check if meters or inches in
the DV_QUANTITY conforms to this C_QUANTITY? How is it supposed to do that,
it seems to me that the C_QUANTITY then must know what allowable units there
can be for the length property. Where are those units supposed to be stored
if only the property is set in the C_QUANTITY?
By the way, shouldn't the property attribute represent a CODED_TEXT
object that can be linked to a local or external terminology?
this is true; we watered it down to make people in CEN and HL7 happy, but
I no longer believe such compromises are sensible. We will probably change
this to a CODED_TEXT.
Ok, I suppose you're referring to the Ocean archetype editor now?
Regards,
Mattias
hope this helps
- thomas beale
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
Questions about archetype definition
Hello, I have some questions about the archetype definition. Currently, I am using the java parser to get an archetype object and from that object I get the archetype definition, which is a CComplexObject. I then pass this object to a recursive function of mine to get hold of some node id's, reference model type names, reference model attribute names and so on. In the function I first get the attributes of the complex object, then I get the children of each attribute and finally I also get some of the children's actual values in the case they aren't complex objects that have to be passed to the function again. Sadly, I haven't found another way to get the children's actual values, than doing a lot of type casting, i.e. to get the value of an object of the type DvBoolean I first have to check if the child is a CPrimitiveObject to get the CPrimitive and then I have to check if the CPrimitive is a CBoolean to get the DvBoolean and finally I can get the actual value of the boolean. I think this is rather tedious, and I would be glad if anyone knows an easier way to do this. In the recursive function I've just described I also try to build a tree structure of the java type DefaultMutableTreeNode in order to to display the archetype definition in a swing object called JTree. I have almost got it right, but I have problems with the levels of the nodes because I cannot simply do recursion over the CComplexObject that represents the definition since I have to get its attributes and the attributes' children (e.g. to see if the children are another CComplexObject), and thus this gets complicated and the assembled final tree is somewhat messed up. I would be glad if anybody had any ideas or advice about this problem and I hope my questions aren't too stupid. Regards, Mattias Forss (MSc student) Medical Informatics group at the Department of Biomedical Engineering Link?pings universitet, Sweden -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050928/48a98e02/attachment.html
