Constraints on class methods
Sebastian Garde wrote: A few other functional properties come to mind such as type in PARTY_RELATIONSHIP ... Re type: This is the same as the property name (because of the type_validity invariant) Yes, funny you should mention that, Sebastian, because I discovered yesterday that this is a bug in the spec. As is well known, the name must be unique among siblings within a container. This uniqueness is incompatible with the PARTY_RELATIONSHIP type, because it would be common for a party to have multiple relationships of the same type. http://www.openehr.org/issues/browse/SPECPR-54 discusses this. I had to find a work around for it in my software. I chose to violate the type_validity invariant: when setting the type, I append a sequential number to it to set the name; and I compute the type by stripping the sequential number off the name. This ensures that the name is unique, while permitting multiple siblings of the same type. - Peter
Carriage returns in DV_TEXT not allowed
Thomas Beale wrote: This does not actually solve properly the problem of how CR/LFs are added. If we assume one DV_PARAGRAPH = 1 CR/LF (as in word processing) then a report needs to consist of multiple DV_PARAGRAPHs, and we don't currently have a data type for that. To fix the current model we could add a new type DV_DOCUMENT, which contains multiple DV_PARAGRAPHs. You could model multiple paragraphs as a LIST of DV_PARAGRAPH. I think the DV_DOCUMENT idea would be unnecessary, unless you wanted to specify additional information such as sections or chapters within the document. - Peter
Carriage returns in DV_TEXT not allowed
Thomas Beale wrote:
You could model multiple paragraphs as a LIST of DV_PARAGRAPH.
but there is no 'LIST' data type to contain the DV_PARAGRAPHs.
Sorry, not a LIST, I meant a multiple-occurrence element like this:
ELEMENT[at0009] occurrences matches {0..*} matches {-- My document
value matches {
DV_PARAGRAPH matches {*}
}
}
In data this would become a sequences of paragraphs.
By the way, I wanted to generate the above ADL in Archetype Editor, but I
discovered that DV_PARAGRAPH hasn't been implemented there yet! There's never
even been a feature request for DV_PARAGRAPH in Archetype Editor. To write the
above example, I had to generate another data type in AE and then edit the data
type by hand. I guess it would be safe to assume, then, that almost no one
would be using DV_PARAGRAPH.
- Peter
Carriage returns in DV_TEXT not allowed
# IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The CTC is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the CTC. If you receive this e-mail in error, please immediately delete it and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. # -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/3e9fcbe6/attachment.html
Carriage returns in DV_TEXT not allowed
Colin Sutton wrote: Couldn?t the text stored in the eHR include HTML paragraph separators, replacing Windows or Unix specific line separators? And HTML escape sequences?. DV_HTMLTEXT? That's what DV_PARSABLE is for, as Thomas mentioned ;-) - Peter
Carriage returns in DV_TEXT not allowed
So, should the answer to Leonardo's question be to use DV_PARSABLE , with value= string, formalism =(unix/windows/mac ;ANSI/UTF8... )? Colin From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of Leonardo Moretti Sent: Tuesday, 10 January 2012 9:05 PM To: openehr-technical at openehr.org Subject: Carriage returns in DV_TEXT not allowed If DV_TEXT doesn't allow to use carriage returns, line feeds, or other non-printing characters, as stated in http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf, pag 29, there is a way to represent short text with minimal formatting characters (carriage returns)? Which data type should be used? Thank you. Regards leo # This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal # IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The CTC is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the CTC. If you receive this e-mail in error, please immediately delete it and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. # -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/b78f372a/attachment.html
openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL
to individually check each date, but we would need this data to determine the best date * If you want to be anonymous, no problem - please put something like Sweden #14, Brazil #38, etc * OR... if you like the idea but don't like the location or timing, please say something on the clinical or technical list in response to this post. THE INTENDED OUTCOME OF THE POLL IS TO DETERMINE: * how many people (roughly) are interested, and would come sometime in the period available * which week should be booked for the conference, since this has to be locked in very soon One variable that could also be changed is duration. Some people might want more of a short working meeting - as far as I can see, there is no way to include this idea on the doodle poll; please indicate on the lists. If you like the conference idea, but can't participate in the above proposal, or would like some other proposal, please post you ideas instead on the lists. thanks for your input. - thomas beale -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/cbb2e69c/attachment.html
openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL
cover costs. WHAT WE NEED TO DO NOW (AND QUICKLY): * If the above sounds interesting, a window is open for this Lake Bled, mid-Sep - mid-Oct. I have created an online poll to gauge interest: * INSTRUCTIONS: * go to the doodle poll http://www.doodle.com/mry4ky77nnzpacu9 * please check contiguous days that could work for you as a conference week - CHECK ALL DAYS OPEN FOR YOU. It's a bit annoying, seems you have to individually check each date, but we would need this data to determine the best date * If you want to be anonymous, no problem - please put something like Sweden #14, Brazil #38, etc * OR... if you like the idea but don't like the location or timing, please say something on the clinical or technical list in response to this post. THE INTENDED OUTCOME OF THE POLL IS TO DETERMINE: * how many people (roughly) are interested, and would come sometime in the period available * which week should be booked for the conference, since this has to be locked in very soon One variable that could also be changed is duration. Some people might want more of a short working meeting - as far as I can see, there is no way to include this idea on the doodle poll; please indicate on the lists. If you like the conference idea, but can't participate in the above proposal, or would like some other proposal, please post you ideas instead on the lists. thanks for your input. - thomas beale -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/eadee453/attachment.html
Constraints on class methods
If you still say that properties can be restricted, then current stable validated bmm files are incorrect, as they are currently missing 90% of stored properties (all methods without parameters), like all the ones in ITEM_TABLE. 2012/1/10 Thomas Beale thomas.beale at oceaninformatics.com: On 10/01/2012 14:32, David Moner wrote: Doesn't this create problems while using archetypes/templates as basis for the generation of data instances? I mean, a computed attribute (for example, the EVENT offset) gets its value from already existing values or attributes of the instance class (in this example, from the time and the parent.origin). We should not create the instance if data is not valid regarding the archetype/template, but we cannot check the validity of the constrained offset while we don't have the instance complete. It seems somehow a vicious circle. An assertion here is clearly preferable, since by definition it is only applied to existing instances. David David, the usual situation in operational systems is that there are RM objects being created by some process. These will not by default obey the template and its archetypes, only the RM; to make the instances obey the template, you have to do something specific, e.g. engineer (or generate) the UI so it only allows exactly what the template says, or... if you have a custom UI (still the case in most real systems today) you will make calls to some programming object to either set or check the data. If you use the 'Template Data Object' approach - an API generated from the template, various types of checking are done. Usually, the checks are done after a 'commit' call is made, and any wrongly set fields have to be fixed by making a new call with appropriate data. This is a similar to the process of the typical web-page on a booking site, where you can't get to the next page until there are no more 'red' fields to correct. There are a lot of different ways to technically do this data setting, too many to explain here, but in essence, a RM-valid but template-invalid RM instance is always possible in the instance building phase; what can't happen in a proper system is for non template-compliant data to be committed to the EHR repository. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
pass_through attribute in ADL 1.5
If it is really needed for the moment for representing templates then it's OK with me (as long as we agree that this is a temporal thing), but I still feel that having two separated places to rule UI generation is a bad idea. I think that annotations could work for you (even creating a new specific ADL section would). We currently have all the GUI directives for representation in a documentation file for each reference model (as you can see in this screen capture http://i.imgur.com/tQxRt.png). This could be extended to general templates in similar way to the one that Pablo has posted. on the other hand, EHRFlex uses a complete MVC architecture, in which the intermediate model (which also depends of your RM) is the one responsible to transform archetypes/templates into classes that the 'view' part can then paint. 2012/1/10 pablo pazos pazospablo at hotmail.com: Hi Diego Thomas, I think this should be out of the scope of the new semantic/structural archetypes templates specs, and should be included in a new specification of GUI Templates. I been working on this subject for a while and want to formalize a XML format to have GUI directives / GUI definition (input controls, position, visibility, order, ...) and binding with structural archetypes and templates (in a system this bindings should be to OPTs). http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates On february/march 2012 I'll be working on this to improve the flexibility of our current templates: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn%2Ftrunk%2Fopen-ehr-gen%2Ftemplates%2Fhce If anyone want to work on this, would be a pleasure to colaborate. FYI: We have developed a prototype editor for those GUI templates: http://code.google.com/p/template-editor-open-ehr-gen/ It is web based, and can access archetypes repositories via HTTP to pull archetypes to be included in a GUI template. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 9 Jan 2012 19:03:32 + From: thomas.beale at oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: pass_through attribute in ADL 1.5 On 05/01/2012 08:54, Diego Bosc? wrote: Put a couple of comments on the wiki, but I think it is a thing that should be discussed on the list. In ADL 1.5 a flag 'pass_through' was added. Its definition is 'Allows nodes required for structuring data but otherwise redundant for screen display and reporting to be detected by rendering software'. So now we have a GUI directive on the ADL. Shouldn't this be a part of the reference model information (if it is never supposed to be displayed) or part of a 'visualization template' (another different level). I would say that more information about visualization will be needed, and having visualization information separated between two different places feels like a bad design move. In general I am inclined to agree, and I have to say I have been in two minds about having this attribute in there. I am convinced by clinical modellers who say that something is needed to control interior tree nodes not appearing on the GUI (indeed, it is visual pollution). And - even if the template were being used to build a message definition (generated XSD or similar), and the data were processed into some report or other output, this attribute would be respected (technically, this is still 'user interface'). I know the passthrough attribute is used often from the current .oet template usage, so we need a way of dealing with the requirement. If we take it out, and say it is a GUI directive, the problem is we currently have no formal framework for that yet. Maybe the lesser of two evils is to do what Koray (I think?) said, and make it a special kind of annotation. I have implemented annotations in ADL/AOM 1.5, and they work nicely. We need to agree on some kind of standard representation, e.g. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Carriage returns in DV_TEXT not allowed
I don't think DV_PARAGRAPH is a good solution for me. I think the construct
of DV_TEXT/DV_PARAGRAPH is too much complex to be used: we need to have an
?ad hoc text editor? to show and set the content of DV_PARAGRAPH. Moreover,
I don't see which are the real advantages this approach gives: although
DV_PARAGRAPH gives a sort of structure to text, this remain a free text, not
coded, and without any metadata associated to DV_TEXT lines.
Whatever I need to use text containing some words that are hyperlinked /
coded / formatted, I prefer to use DV_PARSABLE, where a plain formalism is
used (formalism matches {text/plain}).
Anyway, carriage returns, tabs, line feeds are not parts of a specific
formalism, but just characters. I think this is an excessive restriction (at
least because I don't see the need for this restriction). Other data types,
as ISO ST, let to use any valid unicode characters.
leo
Thomas Beale-3 wrote:
On 10/01/2012 10:05, Leonardo Moretti wrote:
If DV_TEXT doesn't allow to use carriage returns, line feeds, or other
non-printing characters, as stated in
http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf,
pag 29, there is a way to represent short text with minimal formatting
characters (carriage returns)? Which data type should be used?
It would be interesting to know how many other implementers agree with
this restriction. It was put in (from memory) in the very early days of
modelling, based on GEHR, and possibly somewhat on 13606 - nearly 10
years ago!
The idea was that DV_TEXT models a 'text fragment', essentially the idea
of a word, string of words, sentence or possibly a group of sentences.
No CR/LF were allowed because this is taken as a paragraph delimiter,
and the type DV_PARAGRAPH was defined to represent multiple DV_TEXTs
making up a long tract of text like a report. In proper word processing
publishing, this is correct; a 'paragraph' has no CR/LF in it, which
is what allows resizing to work properly in different screen / form
widths.
Additionally, any 'atomic' text item, e.g. a single disease name, single
sentence etc - which make up the majority of text data within structured
data - should not have a CR/LF.
This way of thinking may be dated, and it is a good question as to when
a piece of text can't be a single DV_TEXT. If we stick with the current
model
http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109597816149_873308_762Report.html
(and remember, a DV_CODED_TEXT is-a DV_TEXT in openEHR), the openEHR RM
is imposing a simple word processing model of 'paragraphs' made up of
'text fragments'. An alternative would be to allow anything in a
DV_TEXT. The decision about when you have to have a new DV_TEXT is made
on the basis of attributes other than the actual string value, i.e.:
* hyperlink: if there is a hyperink, it applies to the entire DV_TEXT;
therefore, if you only want a link to correspond to 2 words, then
those 2 words = 1 DV_TEXT
* formattting: simple formatting like bolding, emphasis (about the
same level as typical wiki markup) applies to the whole DV_TEXT;
* mappings: coded mappings, e.g. ICD code applies to whole DV_TEXT;
need to use multiple DV_TEXTs if only some words are to have an
associated code mapping
* formal coding: if a DV_CODED_TEXT is to be used - i.e. when the
string value is the term for the code from its terminology (not just
some mapping), then the DV_CODED_TEXT.value can only consist of the
exact word string to which the code corresponds; more DV_TEXTs have
to be added using a DV_PARAGRAPH to construct a whole paragraph
The best approach with the current model is:
* for atomic text items, e.g. single word/sentence answers to
questions, single coded terms like names of diseases, procedures
etc, use a single DV_CODED_TEXT or DV_TEXT.
* for a tract of text containing some words that are hyperlinked /
coded / formatted, use a DV_PARAGRAPH containing multiple DV_TEXTs.
* Or else you use a DV_PARSABLE, containing XML, HTML, RTF or whatever
you like - but ... no guarantee the receiver can read it!
This does not actually solve properly the problem of how CR/LFs are
added. If we assume one DV_PARAGRAPH = 1 CR/LF (as in word processing)
then a report needs to consist of multiple DV_PARAGRAPHs, and we don't
currently have a data type for that. To fix the current model we could
add a new type DV_DOCUMENT, which contains multiple DV_PARAGRAPHs. Or we
could remove the restriction on CR/LF on DV_TEXT, but that then would
allow CR/LFs to occur in single DV_CODED_TEXT strings, which is almost
certainly an error. But maybe we just assume that software never makes
this error?
The real question is: do we want to have any explicit word-processor
like model of text? 10 years ago, the answer seemed obvious: yes,
because there is no reliable standard of
How is assumed value marked on domain types? (in XML)
Diego,
See me response to this on the java mailing list.
Cheers,
Rong
On 6 January 2012 00:27, Diego Bosc? yampeku at gmail.com wrote:
I am using XMLserializer from Java implementation
2012/1/6 Heath Frankel heath.frankel at oceaninformatics.com:
Diego,
What tool are you using to generate your AOM XML?
The tool issue tracker may be a more appropriate place for these tooling
issues.
Heath
On 05/01/2012 10:34 PM, Diego Bosc? yampeku at gmail.com wrote:
In ADL, the assumed value of a domain type is marked like this:
defining_code matches {
? ? ? ? ? ? ? ? ? ? ? ?[local::
? ? ? ? ? ? ? ? ? ? ? ?at1000, ? ? ? ? -- Standing
? ? ? ? ? ? ? ? ? ? ? ?at1001, ? ? ? ? -- Sitting
? ? ? ? ? ? ? ? ? ? ? ?at1002, ? ? ? ? -- Reclining
? ? ? ? ? ? ? ? ? ? ? ?at1003, ? ? ? ? -- Lying
? ? ? ? ? ? ? ? ? ? ? ?at1014; ? ? ? ? -- Lying with tilt to left
? ? ? ? ? ? ? ? ? ? ? ?at1001] -- assumed value
}
but in the xml form, the assumed value is missing. The schema does not
reflect this (I know it is outdated)
children xsi:type=C_CODE_PHRASE
? ? ? ? ? ? ? ? ? ? ? ? ? ?rm_type_nameCODE_PHRASE/rm_type_name
? ? ? ? ? ? ? ? ? ? ? ? ? ?occurrences
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?lower_includedtrue/lower_included
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?upper_includedtrue/upper_included
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?lower_unboundedfalse/lower_unbounded
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?upper_unboundedfalse/upper_unbounded
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?lower0/lower
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?upper1/upper
? ? ? ? ? ? ? ? ? ? ? ? ? ?/occurrences
? ? ? ? ? ? ? ? ? ? ? ? ? ?node_idat0009/node_id
? ? ? ? ? ? ? ? ? ? ? ? ? ?terminology_id
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?valuelocal/value
? ? ? ? ? ? ? ? ? ? ? ? ? ?/terminology_id
? ? ? ? ? ? ? ? ? ? ? ? ? ?code_listat1000/code_list
? ? ? ? ? ? ? ? ? ? ? ? ? ?code_listat1001/code_list
? ? ? ? ? ? ? ? ? ? ? ? ? ?code_listat1002/code_list
? ? ? ? ? ? ? ? ? ? ? ? ? ?code_listat1003/code_list
? ? ? ? ? ? ? ? ? ? ? ? ? ?code_listat1014/code_list
? ? ? ? ? ? ? ? ? ? ? ? ?/children
Can we reach a quick consensus on how should this be stated? Can we
use an assumed_value label as in all other types?
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Python / Django experience??
Hi all, Would any of you with Python / Django experience be interested in helping with a small open-source project to establish a 'Clinical Knowledge Incubator' website under the auspices of the Foundation? The intention is to establish a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. This is not intended to compete with a more formally-governed repository such as CKM but to allow archetypes, requirements and specification documents to be shared and discussed prior to more formal governance and development processes kicking in. The site will be based on the open source Snowcloud Clinical Templates framework see clinicaltemplates.org. The work needing done to adapt this for openEHR is broadly .. 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution but the limited versioning afforded by Dropbox is probably sufficient. 2. Add the ability to import from openEHR ADL/XML and .opt XML ) into the native XML format. Derek Hoy, the Snowcloud developer, has already partially implemented this but it does need further work. Derek has been good enough to offer further support and guidance. 3. At some point some sort of integration with CKM would be interesting. I will be taking an interest in the developments but have very limited Python skills. Anyone interested? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care ?www.phcsg.org
openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL
to help cover costs. WHAT WE NEED TO DO NOW (AND QUICKLY): * If the above sounds interesting, a window is open for this Lake Bled, mid-Sep - mid-Oct. I have created an online poll to gauge interest: * INSTRUCTIONS: * go to the http://www.doodle.com/mry4ky77nnzpacu9doodle poll * please check contiguous days that could work for you as a conference week - CHECK ALL DAYS OPEN FOR YOU. It's a bit annoying, seems you have to individually check each date, but we would need this data to determine the best date * If you want to be anonymous, no problem - please put something like Sweden #14, Brazil #38, etc * OR... if you like the idea but don't like the location or timing, please say something on the clinical or technical list in response to this post. THE INTENDED OUTCOME OF THE POLL IS TO DETERMINE: * how many people (roughly) are interested, and would come sometime in the period available * which week should be booked for the conference, since this has to be locked in very soon One variable that could also be changed is duration. Some people might want more of a short working meeting - as far as I can see, there is no way to include this idea on the doodle poll; please indicate on the lists. If you like the conference idea, but can't participate in the above proposal, or would like some other proposal, please post you ideas instead on the lists. thanks for your input. - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical J. Richard Dixon Hughes Managing Director, DH4 Pty Limited 86 Cabramatta Road, Mosman, NSW 2088 Phone: +61 (0) 2 9953 8544 Mobile/Cell: +61 (0) 410 549 396 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/c87d7980/attachment.html
pass_through attribute in ADL 1.5
Hi Paplo, Your suggestion here is too oriented to GUI uses cases. As Tom indicated, pass_through is intended to support other data oriented contexts such as flattening schema and class hierarchies, this is why is was generalised from hide-on-form as used in the template designer. If you look at the Operational Template exported in the Template Designer there is an AOM extension of view-constraints which structurally are the same as annotations where there is a hash of paths of hash of constraint name. This supports the pass_through constraint and any other constraints of this class. The term view was adopted because it is used in both GUI and data oriented contexts. I can provide the XML schema for this AOM extension used by the template designer if people are interested. Heath On 10/01/2012 11:47 AM, pablo pazos pazospablo at hotmail.com wrote: Hi Diego Thomas, I think this should be out of the scope of the new semantic/structural archetypes templates specs, and should be included in a new specification of GUI Templates. I been working on this subject for a while and want to formalize a XML format to have GUI directives / GUI definition (input controls, position, visibility, order, ...) and binding with structural archetypes and templates (in a system this bindings should be to OPTs). http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates On february/march 2012 I'll be working on this to improve the flexibility of our current templates: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn%2Ftrunk%2Fopen-ehr-gen%2Ftemplates%2Fhce If anyone want to work on this, would be a pleasure to colaborate. FYI: We have developed a prototype editor for those GUI templates: http://code.google.com/p/template-editor-open-ehr-gen/ It is web based, and can access archetypes repositories via HTTP to pull archetypes to be included in a GUI template. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos http://twitter.com/ppazos -- Date: Mon, 9 Jan 2012 19:03:32 + From: thomas.beale at oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: pass_through attribute in ADL 1.5 On 05/01/2012 08:54, Diego Bosc? wrote: Put a couple of comments on the wiki, but I think it is a thing that should be discussed on the list. In ADL 1.5 a flag 'pass_through' was added. Its definition is 'Allows nodes required for structuring data but otherwise redundant for screen display and reporting to be detected by rendering software'. So now we have a GUI directive on the ADL. Shouldn't this be a part of the reference model information (if it is never supposed to be displayed) or part of a 'visualization template' (another different level). I would say that more information about visualization will be needed, and having visualization information separated between two different places feels like a bad design move. In general I am inclined to agree, and I have to say I have been in two minds about having this attribute in there. I am convinced by clinical modellers who say that something is needed to control interior tree nodes not appearing on the GUI (indeed, it is visual pollution). And - even if the template were being used to build a message definition (generated XSD or similar), and the data were processed into some report or other output, this attribute would be respected (technically, this is still 'user interface'). I know the passthrough attribute is used often from the current .oet template usage, so we need a way of dealing with the requirement. If we take it out, and say it is a GUI directive, the problem is we currently have no formal framework for that yet. Maybe the lesser of two evils is to do what Koray (I think?) said, and make it a special kind of annotation. I have implemented annotations in ADL/AOM 1.5, and they work nicely. We need to agree on some kind of standard representation, e.g. ___ 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/20120111/164f0a7f/attachment.html
Carriage returns in DV_TEXT not allowed
in single DV_CODED_TEXT strings, which is almost certainly an error. But maybe we just assume that software never makes this error? The real question is: do we want to have any explicit word-processor like model of text? 10 years ago, the answer seemed obvious: yes, because there is no reliable standard of marked up text (many variants of HTML, XML, wiki markup, etc). I am not sure the answer is any different today. From a clinical perspective, guaranteeing readability of text in a standard way is paramount. - thomas ___ 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/20120111/df44dca2/attachment.html
How to use C_DURATION pattern constraint
Hi all,
maybe this is a silly question, but I didn't find a point in the specs
where this is clearly explained:
The following notation on ADL:
ELEMENT[at0009] occurrences matches {0..1} matches { -- Pattern
value matches {
DV_DURATION matches {
value matches {PYM}
}
}
}
constraints the data to have a DV_DURATION element with both year and month
specified (both part are mandatory) or with year and/or month specified
(both part are optional)!?
Thanks
leo
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/975e4703/attachment.html
pass_through attribute in ADL 1.5
Hi Heath,Hi Paplo, Your suggestion here is too oriented to GUI uses cases. As Tom indicated, pass_through is intended to support other data oriented contexts such as flattening schema and class hierarchies, this is why is was generalised from hide-on-form as used in the template designer. In that case, I think we should separate the uses of the directive. IMO is a little anoying to use the same directive to do semantic processing of the structure and to do GUI generation/customization. If you look at the Operational Template exported in the Template Designer there is an AOM extension of view-constraints which structurally are the same as annotations where there is a hash of paths of hash of constraint name. This supports the pass_through constraint and any other constraints of this class. I'm afraid I could not see what you mention, I don't have a licence for the TD. The term view was adopted because it is used in both GUI and data oriented contexts. I can provide the XML schema for this AOM extension used by the template designer if people are interested. It would be nice to see the schema and some documentation about the structure and rationale behind it if you have some (just to understand the XML structure). Cheers, Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/e7b661d9/attachment.html
pass_through attribute in ADL 1.5
Hi! From: yampeku at gmail.com Date: Wed, 11 Jan 2012 10:12:39 +0100 Subject: Re: pass_through attribute in ADL 1.5 To: openehr-technical at openehr.org If it is really needed for the moment for representing templates then it's OK with me (as long as we agree that this is a temporal thing), but I still feel that having two separated places to rule UI generation is a bad idea. I totally agree with Diego. I think that annotations could work for you (even creating a new specific ADL section would). We currently have all the GUI directives for representation in a documentation file for each reference model (as you can see in this screen capture http://i.imgur.com/tQxRt.png). This could be extended to general templates in similar way to the one that Pablo has posted. on the other hand, EHRFlex uses a complete MVC architecture, in which the intermediate model (which also depends of your RM) is the one responsible to transform archetypes/templates into classes that the 'view' part can then paint. EHRGen also is MVC but we generate HTML forms for creating editing clinical records, and a other HTMLs for showing individual records (documents/compositions). Maybe we could share our current GUI directive formalisms to think about a new/common formal way to express all the things we need to generate GUI. I also want to work on generation of reports with aggregated data, trying to reuse what we could for the GUI generation for clinical recording viewing. Cheers,Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/480d646c/attachment.html
