Hi Diego, 'pass-through' is required to construct clear clinical views of template models in some circumstances. I think the suggestion to use the annotations feature makes sense.
A common example might be where a complex Discharge summary requirement asks for a Diagnosis field. This would be modelled as something like EVALUATION. diagnosis.v1 items Diagnosis name From a clinical review perspective the EVALUATION root node and items node are redundant, and it is confusing to have them appear in the tooling views It would be great if we could make some progress on a GUI templating formailsm putting together the work done in EHRFlex, Koray's GastrOS directives and, of course, Pablo's work, bearing in mind that at least some of the directives and transformations have utility in other outputs e.g Documentation and not just in GUI production. 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 On 11 January 2012 09:12, Diego Bosc? <yampeku at gmail.com> wrote: > 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 +0000 >> 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 >> > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
