GUI-directives/hints again (Was: Developing usable GUIs)
Hi Thomas, It's been a while. I've added some thoughs on GUI directives to improve our Open EHR-Gen GUI Templates. It may help to create something more generic than an improvement to our templates. http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates My grain of sand. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Wed, 15 Dec 2010 20:44:49 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) On 15/12/2010 00:57, pablo pazos wrote: Hi Thomas, ... You describe a very big picture and sounds logic, so we'll have: Level 1: archetypes (for model complete data sets about a concept, general and specialized ones) Level 2: structural templates (for localized use of archetypes, general and specialized templates) Level 3: define the use of the structural templates GUI Templates: define directives over a couple of Structural Templates to create a graphic representations of some archetyped data. Message Templates: define directives to structure archetyped data into messages with some syntax (HL7 v2, v3, 13606, CCR, CCD, CDA ...). to do non-openEHR message syntaxes, it requires not just another 'template' (in fact, not much be needed here), but a transformation from the operational template (OPT) form to the target form, e.g. CCR XSD or whatever. Report Templates: create reports with aggregated data and graphic representations like charts. Can be used by GUI Templates. Information Aggregation Templates: to define data aggregation rules over a set of archetyped data. Can be used by GUI Templates, Report Templates, etc. Rule Templates: to define rules over a set of archetyped data to check validity, consistency, etc, etc. Can be used by Decision Support Modules, e.g. to check medication reactions. ... I am not sure what some of these would look like, but I suspect they will come into existence one day... If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section? I have a couple ideas that can improve what we've done on the EHR-Gen framework. If you want I can put them in the wiki. please do that - 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/20110128/43dc4c51/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi! On Wed, Dec 15, 2010 at 00:30, Thomas Beale thomas.beale at oceaninformatics.com?wrote: On 10/12/2010 08:49, Erik Sundvall wrote: If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray,?Pablo and others?) to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section? Yes, I was then thinking of section 9.8 in http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf When looking closer at this for GUI hint experimentation, perhaps we could instead use a combination of annotations and the assertion/rule mechanisms in ADL/AOM? The already present logic in the assertions mechanism is probably enough to define e.g. Boolean trigger variables. Annotations could then be used to let GUIs know what to do/show/hide based on those triggers. Discussion examples follow (with the risk of ADL errors that Tom's brain-integrated ADL parser :-) will catch and he then can correct) In section?6.5.4 of http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf a way of defining variables is specified. Perhaps a (preferably Boolean) variable could be defined as an archetype rule like... $smoker:BOOLEAN ::= /data/items[at0003.7]/items[at0009.3]/value/defining_code matches local::at0013 ...and an annotation on a tree structure that should be shown in GUIs only when documenting smokers could be... annotations = [/data/items[at0003.7]/items[at0010]] = items = [GUI-show-if] = $smoker -- Other annotation name examples: GUI-hide-if ... [some other annotation] = whatever ...or perhaps... annotations = [/data/items[at0003.7]/items[at0010]] = items = [GUI-trigger] = $smoker [GUI-action] = show -- Other annotation value examples: hide, collapse, expand [some other annotation] = whatever I guess the mess starts if such annotations are to be overridden in yet a specialization generation of the GUI-annotated template/archetype. That would have to be analyzed further, but maybe some refined variant of the examples above could be a useful start in the mean time? Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 On Wed, Dec 8, 2010 at 15:55, Thomas Beale?thomas.beale at oceaninformatics.com?wrote: you have two choices: A) mix it in with the languages architectural layers you already have B) create a dedicated layer or component type, and possibly dedicated formalism if needed Erik Sundvall wrote: I believe there is (as usual) a context dependent gray-zone, not a clear breakpoint, regarding what annotations would be most useful to have in which layer. So, yes I agree layers are good for separation of concerns, but it is not always (at least not at an early stage) easy to forsee exactly what best fits into each layer and how many layers there should be. Thomas Beale wrote: I agree - we don't yet have a clear list of the GUi semantics that would need to be in a UI template...
GUI-directives/hints again (Was: Developing usable GUIs)
On 20/12/2010 12:05, Erik Sundvall wrote: Hi! On Wed, Dec 15, 2010 at 00:30, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 10/12/2010 08:49, Erik Sundvall wrote: If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section? Yes, I was then thinking of section 9.8 in http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf When looking closer at this for GUI hint experimentation, perhaps we could instead use a combination of annotations and the assertion/rule mechanisms in ADL/AOM? The already present logic in the assertions mechanism is probably enough to define e.g. Boolean trigger variables. Annotations could then be used to let GUIs know what to do/show/hide based on those triggers. I will have annotations implemented in the next few days, with some test archetypes. We will put a release up in hopefully 10 days, and people can play. BTW: the current draft online is incorrect: it misses a language level in the annotations structure (i.e. annotations are linguistic entities so they need to be defined under a specified language just like terms on the ontology section). The structure I implement will also be put online. Then all requests for change will be considered ;-) I have to beef up the implementation of the invariant (now called rules) section; then we can try to implement this example below... - thomas Discussion examples follow (with the risk of ADL errors that Tom's brain-integrated ADL parser :-) will catch and he then can correct) In section 6.5.4 of http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf a way of defining variables is specified. Perhaps a (preferably Boolean) variable could be defined as an archetype rule like... $smoker:BOOLEAN ::= /data/items[at0003.7]/items[at0009.3]/value/defining_code matches local::at0013 ...and an annotation on a tree structure that should be shown in GUIs only when documenting smokers could be... annotations = [/data/items[at0003.7]/items[at0010]] = items = [GUI-show-if] =$smoker -- Other annotation name examples: GUI-hide-if ... [some other annotation] =whatever ...or perhaps... annotations = [/data/items[at0003.7]/items[at0010]] = items = [GUI-trigger] =$smoker [GUI-action] =show -- Other annotation value examples: hide, collapse, expand [some other annotation] =whatever I guess the mess starts if such annotations are to be overridden in yet a specialization generation of the GUI-annotated template/archetype. That would have to be analyzed further, but maybe some refined variant of the examples above could be a useful start in the mean time? Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
GUI-directives/hints again (Was: Developing usable GUIs)
Hi, I don?t mean to be too pushy on this but I think we are not really on the
same grounds at the moment. I?ll try to summarise my points:
- Re universality I agree with you as you describe but I have
indicated that this pattern is unique to certain type of observations; so
perhaps I shouldn?t have used the term universal but ?common? in many types of
clinical findings as a result of some examination. The exclusions you give by
examples are very appropriate.
- It is perfectly possible, and indeed during the diagnosis of acute
appendicitis essential, to denote absence of lump or ?lack of rebound reflex?
is almost common expression and pathognomonic to the disease. So I don?t agree
with you and my gut feeling is that all findings during physical examination
may well be reported as absent.
- Yes I?d be also very interested to identify and classify if possible
which ones ? but again my gut feeling is that this may not be possible and that
relies on the clinical context and semantics. Therefore instead of identifying
these at the outset I think giving the modellers a method to tag these will be
the pragmatic solution and enable consistency among modellers and
implementations.
- Re design patterns and tooling support ? I think this should be in
place in any case. But as Ian has pointed out there is more to the problem than
convenience for modellers. The problem is consistency among modellers and mode
critically when these models need to evolve (which is almost guaranteed) then
how to avoid changes in paths?i.e. many ELEMENTs will need to be converted to
CLUSTERS. Conversely if you anticipate this and design accordingly you might
end up having zillion of unnecessary CLUSTERS with single ELEMENTs?
Hey Ian! I liked your proposal?Never been to Bahamas
Cheers,
-koray
From: openehr-clinical-bounces at openehr.org
[mailto:openehr-clinical-boun...@openehr.org] On Behalf Of Sam Heard
Sent: Thursday, 16 December 2010 9:22 a.m.
To: For openEHR clinical discussions
Cc: openehr-clinical at openehr.org
Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs)
Hi All
I sense Thomas is right. If you look at the exam archetypes there is a pattern
of unlimited normal statements. This allows anything to be said but for it to
be classified as normal even if it is text. There is work to do on examination
as it is fractal and varies on a case by case basis.
Happy to talk about this at the implementation meeting.
Cheers Sam
Sent from my extphoney
On 16/12/2010, at 6:24 AM, Thomas Beale thomas.beale at
oceaninformatics.commailto:thomas.beale at oceaninformatics.com wrote:
On 15/12/2010 19:20, Koray Atalag wrote:
Hi Tom, I agree that the this is best way how to ?represent? data technically.
But what I suggest is, since this is a universal and repeating pattern for all
clinical findings (and maybe more) can?t we have an extension in ADL such that
we ?tag? a certain sub-tree and then this node is inserted into ADL source
automatically. And the way we write queries and process that would be uniform
and convenient.
Cheers,
I am pretty sure it is not universal. Consider any standard lab, e.g. full
blood count. Each analyte that is reported is there; if a proper value can't be
reported, e.g. haemolysed attached specimen, you get just a report with that in
it; otherwise you get numbers (including things like 'trace' where appropriate)
and normal ranges. This is a different pattern. A reflex test is going to
report a reaction to a stimulus, for each of a number of locations on the body.
This will be a different pattern again ('no reaction' is just a value among
other values of reaction strength).
Your pattern might be a typical pattern for various kinds of physical
examination, where the examination proceeds on the basis of looking for a very
specific set of possible anomalies, in the way that colonoscopy does. But even
then, physical exam of e.g. abdomen is not going to report 'lump: absent' if no
lump was encountered in a routine check.
I agree it is likely to be a common pattern in some kinds of examination, and
it would be interesting to know which ones, and how these could be categorised.
I would suggest that what you are really after is a library of 'archetype
design patterns' that are available to tools, enabling you to quickly build the
definitions for a whole lot of nodes according to a chosen pattern.
My suggestion is to try to identify and document such patterns - I started a
page on this about 1year ago at
http://www.openehr.org/wiki/display/healthmod/Archetype+Design+Patterns+-+Initial+Thoughts
- thomas
___
openEHR-clinical mailing list
openEHR-clinical at openehr.orgmailto:openEHR-clinical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org
GUI-directives/hints again (Was: Developing usable GUIs)
Thanks a lot Helma - lots of reading material for Xmas! Cheers, -koray -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of hepabolu Sent: Wednesday, 15 December 2010 8:58 a.m. To: For openEHR technical discussions Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) Hi everyone, for those interested, my full thesis is available here: http://www.sourcefusion.nl/thesis/Dissertation-HvdL.pdf A link on the openEHR website to this PDF is appreciated. Sorry for not participating in the discussion, but my current job has me swamped with work and deadlines. With regards, Helma van der Linden Thilo Schuler said the following on 13/12/2010 07:20: Hi everybody, I got permission to publish the MedInfo paper and its successor mentioned below. You can find it here (last row of table): http://www.openehr.org/wiki/display/resources/MedInfo+2007+-+Brisbane+Australia Cheers, Thilo After that Helma, her supervisor, Rong and I published a very future-oriented paper http://www.ncbi.nlm.nih.gov/pubmed/17911890?ordinalpos=1itool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_RVDocSum about sharing not only archetypes but also GUI artefacts. Helma later extended this idea in a chapter of her thesis and (re)published http://www.ncbi.nlm.nih.gov/pubmed/19368989 it. I will ask her whether we can put the paper and her thesis on the wiki (maybe she reads this anyway... Hello Helma?). This is definitely far away from end-to-end applications and it is unclear whether it will ever be realisable but it still has some very interesting thoughts for our discussion. An extended version of Lisa's EhrView mechanism http://openehr.org/wiki/display/dev/openEHR+Composition+XML+to+HTML with a repository of XSLT-fragments is - IMO - something that could definitely be realised in the midterm to provide an enhanced read-only view of arbitrary openEHR information. ___ 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
New requirements from endoscopy (was Re: GUI-directives/hints again (Was: Developing usable GUIs))
hi Koray Unknown Indeterminate. (though they overlap) Generally, this is not really an endoscopy requirement. I've seen it come up in all sorts of contexts. (for instance, the Australias structured pathology reports). Even in the case of a list of medications: you can assert that the patient *isn't* taking any medication. Also, you can assert that you're not sure of the entire list, but you know that the patient is *not* taking a medication But it doesn't apply generally - it's a pattern that varies across particular issues. Frustratingly, there's no consistency in the way people think, as far as I can tell, and the various coding systems are even more inconsistent than people's thinking (mainly due to variations in total capture of woolly thinking across issues) With regard to the proposal to have nullFlavor on cluster, HL7 pretty much does this in v3 - all associations have a nullFlavor. But it's a difficult concept - when you say the association is not a proper value - which parts of it? It's like negation - what parts of observed as improper, and what parts properly define the improperness? (LIke negation - what's the scope of the negation?). I don't see why the same concern wouldn't apply to a cluster. It seems to me that this was meant to be solved by having optional clusters with mandatory items. Because of the variations in the pattern, you sometimes write additional constraints - like, for instance, you can't observe any features of a carcinoma if the carcinoma is not present. But usually we don't bother encoding these very obvious things in the models I do think that you have GUI hinting requirements for the template language here. These are the kind of things our kind-of-like-archetype-system focuses on: GUI hints in the templating language Grahame On Wed, Dec 15, 2010 at 1:01 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 14/12/2010 10:44, Koray Atalag wrote: Hi Tom, here is our response: We have so far came across two issues which we believe should be handled at the clinical modelling levels (i.e. RM, archetypes and templates). These have to do with the structure and semantics of the clinical information and underpinned by domain knowledge. 1) During our implementation one change request mandated that we should be able to depict certain data items (endoscopic findings) as present|unknown|absent as well as null if nothing has been specified about it. In the work for Nehta on anatomical pathology models Ian followed a similar approach where some findings were expressed as present, absent or indeterminate as far as I remember and this was definitely a repeating pattern. This caused us to look more carefully into the whole thing and we came to a conclusion that not all data items need/can be represented like that. For example it doesn?t really make sense to indicate absence of a drug in patient?s medication list or a medical procedure performed; they are either present and further qualified (i.e. Aspirin 300mg tid or biopsy performed) or not mentioned at all. However clinical findings, as in our case, essentially require to be depicted as unknown or absent explicitly. We have initially thought we could solve the issue by using flavours of null which is defined by openEHR RM for each ELEMENT data item (caution here it is only for ELEMENT) but the problem is that these findings are represented using CLUSTERs not ELEMENTs in our MST Archetypes. This is because we use ELEMENTs under each CLUSTER to depict properties or attributes of those findings such as size, number extent etc. And we cannot represent Absent with flavours of null either. Koray, I don't get this bit: you are saying you want the effect of flavours of null for whole sub-trees of information? Our workaround in current implementation is that we have inserted to each and every clinical finding CLUSTER a special ELEMENT data item called ?Present?? of DV_CODED_TEXT which have the following? values: 0Null, 1Present, 2Unknown, 3Absent. We don?t further specify the reasons of Unknown but using flavours of null would be logical. Even more interesting when nothing is entered on GUI for a clinical finding or when entered but later on it is ?cleared? instead of putting value 0 for null we can actually ?prune? that particular CLUSTER (and all downstream items); i.e. remove altogether from the value instance. Our solution to this issue was to come up with a GUI Directive called ?isCoreConcept?.? This instructs our GUI generator to render that item with 3- state checkbox and also hide all its children until a value has been selected. This directive also imposes an implicit precondition that the affected CLUSTER define the special child ELEMENT that denotes Present? - otherwise the GUI generator will render the model invalid. Actually when we rethink about this we found out that this particular directive actually is overloaded and has elements of both
GUI-directives/hints again (Was: Developing usable GUIs)
On 15/12/2010 00:57, pablo pazos wrote: Hi Thomas, ... You describe a very big picture and sounds logic, so we'll have: Level 1: archetypes (for model complete data sets about a concept, general and specialized ones) Level 2: structural templates (for localized use of archetypes, general and specialized templates) Level 3: define the use of the structural templates GUI Templates: define directives over a couple of Structural Templates to create a graphic representations of some archetyped data. Message Templates: define directives to structure archetyped data into messages with some syntax (HL7 v2, v3, 13606, CCR, CCD, CDA ...). to do non-openEHR message syntaxes, it requires not just another 'template' (in fact, not much be needed here), but a transformation from the operational template (OPT) form to the target form, e.g. CCR XSD or whatever. Doing futurology here, we could have these mapping rules defined inside the Message Templates, or may be just referencing wich tranformation to use (the output syntax) will suffice. But I'm not sure what will be the inside of one of these templates. Report Templates: create reports with aggregated data and graphic representations like charts. Can be used by GUI Templates. Information Aggregation Templates: to define data aggregation rules over a set of archetyped data. Can be used by GUI Templates, Report Templates, etc. Rule Templates: to define rules over a set of archetyped data to check validity, consistency, etc, etc. Can be used by Decision Support Modules, e.g. to check medication reactions. ... I am not sure what some of these would look like, but I suspect they will come into existence one day... I'm not sure neither, but I'm sure these templates will be part of any openEHR-based EHR. -Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101215/09bc6d96/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Thanks Thile, didn't have this paper before - will read now with much pleasure :) Hong Yul and I had a long discussion yesterday and will prepare a joint response today or tomorrow (well NZ time of course!). Especially Tom has asked whether we have any issues which might need to go into Templates or Archetypes that has to do with the semantics and structure rather than GUI only. We think that we do but need first to define and be able to articulate in plain words. Cheers, -koray From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thilo Schuler Sent: Monday, 13 December 2010 7:20 p.m. To: For openEHR technical discussions Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) Hi everybody, I got permission to publish the MedInfo paper and its successor mentioned below. You can find it here (last row of table): http://www.openehr.org/wiki/display/resources/MedInfo+2007+-+Brisbane+Australia Cheers, Thilo After that Helma, her supervisor, Rong and I published a very future-oriented paperhttp://www.ncbi.nlm.nih.gov/pubmed/17911890?ordinalpos=1itool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_RVDocSum about sharing not only archetypes but also GUI artefacts. Helma later extended this idea in a chapter of her thesis and (re)publishedhttp://www.ncbi.nlm.nih.gov/pubmed/19368989 it. I will ask her whether we can put the paper and her thesis on the wiki (maybe she reads this anyway... Hello Helma?). This is definitely far away from end-to-end applications and it is unclear whether it will ever be realisable but it still has some very interesting thoughts for our discussion. An extended version of Lisa's EhrView mechanismhttp://openehr.org/wiki/display/dev/openEHR+Composition+XML+to+HTML with a repository of XSLT-fragments is - IMO - something that could definitely be realised in the midterm to provide an enhanced read-only view of arbitrary openEHR information. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101214/ac01db6d/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
On 10/12/2010 08:49, Erik Sundvall wrote: Hi! A very interesting discussion, thanks to everybody here! Great with all references too! On Wed, Dec 8, 2010 at 16:26, pablo pazos pazospablo at hotmail.com mailto:pazospablo at hotmail.com wrote: Maybe if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems. Or perhaps GUI focused templates and Structurally focused templates (since both will be openEHR based). Correct me if I'm wrong: If templates can specialize templates in several generations of inheritance/specialisation (This is the case, right?), then we could use the same basic annotation formalism for different purposes in different layers, only the annotation names would be different. So an example inheritance/specialisation hierarchy in a running system could be: A bunch of clinical archetypes (mostly international, and some regional ones) ...are used as building blocks in... a structural template (maybe national/regional) often creating a composite SECTION or COMPOSITION [add more structural layers if useful] all correct up to here ...that is then annotated with GUI-hints by... a set of GUI templates with each template fitting a different recurring use case not forgetting that GUI is only one place to deploy a template (e.g. messages etc), so there might be some other kind of 'deployment templates' as well. ...for a specific GUI, the most fitting of those GUI templates is then picked and might be further annotated/specialized with yet another template layer or used directly as input to GUI-generation or GUI-building tools On Wed, Dec 8, 2010 at 15:55, Thomas Beale thomas.beale at oceaninformatics.com mailto:thomas.beale at oceaninformatics.com wrote: you have two choices: * A) mix it in with the languages architectural layers you already have * B) create a dedicated layer or component type, and possibly dedicated formalism if needed I believe there is (as usual) a context dependent gray-zone, not a clear breakpoint, regarding what annotations would be most useful to have in which layer. So, yes I agree layers are good for separation of concerns, but it is not always (at least not at an early stage) easy to forsee exactly what best fits into each layer and how many layers there should be. I agree - we don't yet have a clear list of the GUi semantics that would need to be in a UI template... If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section? and if could be reused also for GUI-stuff instead of creating another different formalism, then we should take a close look at that option before thinking of specifying another mechanism for GUI-concerns. You'd still get layers (if you sensibly use specialisation) but more flexible boundaries during the needed upcoming period of collaborative experimentation and real use. On Mon, Dec 6, 2010 at 22:06, Koray Atalag k.atalag at auckland.ac.nz mailto:k.atalag at auckland.ac.nz wrote: I think having these discussions is a great start. But it'd be great if someone from the core group 'owns' this thread and puts some pressure on us. Koray, what makes you exclude yourself from the core group? Shouldn't openEHR be a community with peers trying to solve common problems, where people like you with specific implementation experience can help collaboratively lead a specific exploration tangents at least as well as some official core that is busy prioritizing other important explorations. Whatever that core is I believe it will be actively involved in, and appreciate, the discussions. Erik, is right. There is no special 'core group' like in the old days - these days, it is whoever is here. In terms of ADL/AOM 1.5 specs, I will simply take into account any requirements that are clearly enough documented for me to understand... - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101214/60c3b1b6/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Thomas, Correct me if I'm wrong: If templates can specialize templates in several generations of inheritance/specialisation (This is the case, right?), then we could use the same basic annotation formalism for different purposes in different layers, only the annotation names would be different. So an example inheritance/specialisation hierarchy in a running system could be: A bunch of clinical archetypes (mostly international, and some regional ones) ...are used as building blocks in... a structural template (maybe national/regional) often creating a composite SECTION or COMPOSITION [add more structural layers if useful] all correct up to here ...that is then annotated with GUI-hints by... a set of GUI templates with each template fitting a different recurring use case not forgetting that GUI is only one place to deploy a template (e.g. messages etc), so there might be some other kind of 'deployment templates' as well. ...for a specific GUI, the most fitting of those GUI templates is then picked and might be further annotated/specialized with yet another template layer or used directly as input to GUI-generation or GUI-building tools You describe a very big picture and sounds logic, so we'll have: Level 1: archetypes (for model complete data sets about a concept, general and specialized ones)Level 2: structural templates (for localized use of archetypes, general and specialized templates)Level 3: define the use of the structural templatesGUI Templates: define directives over a couple of Structural Templates to create a graphic representations of some archetyped data. Message Templates: define directives to structure archetyped data into messages with some syntax (HL7 v2, v3, 13606, CCR, CCD, CDA ...). Report Templates: create reports with aggregated data and graphic representations like charts. Can be used by GUI Templates. Information Aggregation Templates: to define data aggregation rules over a set of archetyped data. Can be used by GUI Templates, Report Templates, etc. Rule Templates: to define rules over a set of archetyped data to check validity, consistency, etc, etc. Can be used by Decision Support Modules, e.g. to check medication reactions. ... If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section? I have a couple ideas that can improve what we've done on the EHR-Gen framework. If you want I can put them in the wiki. Cheers, -Pablo. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101214/13dec05e/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi everybody, I got permission to publish the MedInfo paper and its successor mentioned below. You can find it here (last row of table): http://www.openehr.org/wiki/display/resources/MedInfo+2007+-+Brisbane+Australia Cheers, Thilo After that Helma, her supervisor, Rong and I published a very future-oriented paperhttp://www.ncbi.nlm.nih.gov/pubmed/17911890?ordinalpos=1itool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_RVDocSumabout sharing not only archetypes but also GUI artefacts. Helma later extended this idea in a chapter of her thesis and (re)publishedhttp://www.ncbi.nlm.nih.gov/pubmed/19368989it. I will ask her whether we can put the paper and her thesis on the wiki (maybe she reads this anyway... Hello Helma?). This is definitely far away from end-to-end applications and it is unclear whether it will ever be realisable but it still has some very interesting thoughts for our discussion. An extended version of Lisa's EhrView mechanismhttp://openehr.org/wiki/display/dev/openEHR+Composition+XML+to+HTMLwith a repository of XSLT-fragments is - IMO - something that could definitely be realised in the midterm to provide an enhanced read-only view of arbitrary openEHR information. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101213/e533c68a/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Koray, Erik, Pablo, Pariya and other GUI interested These are very exciting times for me. I have been interested in openEHR GUIs and GUI generation since the first experiments that the co-authors and I did prior to publishing the MIE 2006 paper that Koray mentioned. For those still interested I uploaded a very late draft [;)] of this old paper to the wikihttp://openehr.org/wiki/display/resources/MIE+2006+-+Maastricht%2C+Netherlands. After that Helma, her supervisor, Rong and I published a very future-oriented paperhttp://www.ncbi.nlm.nih.gov/pubmed/17911890?ordinalpos=1itool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_RVDocSumabout sharing not only archetypes but also GUI artefacts. Helma later extended this idea in a chapter of her thesis and (re)publishedhttp://www.ncbi.nlm.nih.gov/pubmed/19368989it. I will ask her whether we can put the paper and her thesis on the wiki (maybe she reads this anyway... Hello Helma?). This is definitely far away from end-to-end applications and it is unclear whether it will ever be realisable but it still has some very interesting thoughts for our discussion. An extended version of Lisa's EhrView mechanismhttp://openehr.org/wiki/display/dev/openEHR+Composition+XML+to+HTMLwith a repository of XSLT-fragments is - IMO - something that could definitely be realised in the midterm to provide an enhanced read-only view of arbitrary openEHR information. It is great to see/hear that GUI generation is working in two proper end-to-end applications now: - Next week I will continue my explorationhttp://openehr.org/wiki/display/impl/Playing+with+Pablo%27s+Open+EHR-Gen+Frameworkof Open Ehr-Gen - As soon as GastrOS is open-sourced I will give it a spin as well Due to lack of time, money, programming skill, openEHR maturity,... I haven't been involved in this topic anymore lately. This discussion and the before mentioned applications are motivation for me to start again providing my small share to drive this topic further. I think this could be very important for openEHR overall as e.g. web-based Open EHR-Gen will make it easy to demonstrate openEHR to a wider audience. Erik makes a very good point about ownership of this issue. We who are interested and especially those with practical experience should drive this topic. Here from memory a group that has been or is involved with openEHR GUI generation (please add those who I forgot) - Koray Hong Yul - Pablo Leandro - Seref Tony - Helma - Lisa - Rong - Thilo Let's take the max leverage for openEHR out of this discussion! Cheers, Thilo On Fri, Dec 10, 2010 at 7:49 PM, Erik Sundvall erik.sundvall at liu.se wrote: Hi! A very interesting discussion, thanks to everybody here! Great with all references too! On Wed, Dec 8, 2010 at 16:26, pablo pazos pazospablo at hotmail.com wrote: Maybe if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems. Or perhaps GUI focused templates and Structurally focused templates (since both will be openEHR based). Correct me if I'm wrong: If templates can specialize templates in several generations of inheritance/specialisation (This is the case, right?), then we could use the same basic annotation formalism for different purposes in different layers, only the annotation names would be different. So an example inheritance/specialisation hierarchy in a running system could be: A bunch of clinical archetypes (mostly international, and some regional ones) ...are used as building blocks in... a structural template (maybe national/regional) often creating a composite SECTION or COMPOSITION [add more structural layers if useful] ...that is then annotated with GUI-hints by... a set of GUI templates with each template fitting a different recurring use case ...for a specific GUI, the most fitting of those GUI templates is then picked and might be further annotated/specialized with yet another template layer or used directly as input to GUI-generation or GUI-building tools On Wed, Dec 8, 2010 at 15:55, Thomas Beale thomas.beale at oceaninformatics.com wrote: you have two choices: - A) mix it in with the languages architectural layers you already have - B) create a dedicated layer or component type, and possibly dedicated formalism if needed I believe there is (as usual) a context dependent gray-zone, not a clear breakpoint, regarding what annotations would be most useful to have in which layer. So, yes I agree layers are good for separation of concerns, but it is not always (at least not at an early stage) easy to forsee exactly what best fits into each layer and how many layers there should be. If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) and if could be reused also for GUI-stuff instead of creating another different formalism, then we should take a close look at that option before thinking of
GUI-directives/hints again (Was: Developing usable GUIs)
Sorry forgot Thilo's paper info: 1. Schuler T, Garde S, Heard S, Beale T. Towards automatically generating graphical user interfaces from openEHR archetypes. Stud Health Technol Inform 2006;124:221-6. Cheers, -koray From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of pablo pazos Sent: Thursday, 9 December 2010 7:39 a.m. To: openehr technical Subject: RE: GUI-directives/hints again (Was: Developing usable GUIs) Hi Ian, If I understand what Thomas said I would suggest that the GUI templates just reference paths found in the openEHR template, the paths in a GUI Template will come only from openEHR templates (the structural ones), not from archetypes (this is apart from that they are technically the same thing). I think in ADL 1.4 the template specification is not complete, I would say that in 1.4 Templates are not so clear Archetype specializations. In ADL 1.5 is more clear the relationship of Templates and Archetypes. What I meant in the previous mail was: for us who have developed applications over ADL 1.4, our GUI Templates will use paths directly from Archetypes, instead of paths from openEHR structural Templates. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: Ian.McNicoll at oceaninformatics.com Date: Wed, 8 Dec 2010 17:30:38 + Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) To: openehr-technical at openehr.org Hi Pablo, In both ADL1.4 and 1.5 every path is still an archetype-based path. The proposed schema for an operational template is very similar to the XML schema of an individual archetype but obviously includes multiple aggregated archetypes and omits any nodes which are constrained out. Templates are technically identical to specialised archetypes. The difference is that specialised archetypes support templating features such as constraining out unwanted elements and aggregating archetypes. The only difference between an archetype and a template is that new content i.e. new nodes or terms cannot be added to a template. Ian Dr Ian McNicoll office / fax +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101210/d59a3c51/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi! A very interesting discussion, thanks to everybody here! Great with all references too! On Wed, Dec 8, 2010 at 16:26, pablo pazos pazospablo at hotmail.com wrote: Maybe if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems. Or perhaps GUI focused templates and Structurally focused templates (since both will be openEHR based). Correct me if I'm wrong: If templates can specialize templates in several generations of inheritance/specialisation (This is the case, right?), then we could use the same basic annotation formalism for different purposes in different layers, only the annotation names would be different. So an example inheritance/specialisation hierarchy in a running system could be: A bunch of clinical archetypes (mostly international, and some regional ones) ...are used as building blocks in... a structural template (maybe national/regional) often creating a composite SECTION or COMPOSITION [add more structural layers if useful] ...that is then annotated with GUI-hints by... a set of GUI templates with each template fitting a different recurring use case ...for a specific GUI, the most fitting of those GUI templates is then picked and might be further annotated/specialized with yet another template layer or used directly as input to GUI-generation or GUI-building tools On Wed, Dec 8, 2010 at 15:55, Thomas Beale thomas.beale at oceaninformatics.com wrote: you have two choices: - A) mix it in with the languages architectural layers you already have - B) create a dedicated layer or component type, and possibly dedicated formalism if needed I believe there is (as usual) a context dependent gray-zone, not a clear breakpoint, regarding what annotations would be most useful to have in which layer. So, yes I agree layers are good for separation of concerns, but it is not always (at least not at an early stage) easy to forsee exactly what best fits into each layer and how many layers there should be. If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) and if could be reused also for GUI-stuff instead of creating another different formalism, then we should take a close look at that option before thinking of specifying another mechanism for GUI-concerns. You'd still get layers (if you sensibly use specialisation) but more flexible boundaries during the needed upcoming period of collaborative experimentation and real use. On Mon, Dec 6, 2010 at 22:06, Koray Atalag k.atalag at auckland.ac.nz wrote: I think having these discussions is a great start. But it'd be great if someone from the core group 'owns' this thread and puts some pressure on us. Koray, what makes you exclude yourself from the core group? Shouldn't openEHR be a community with peers trying to solve common problems, where people like you with specific implementation experience can help collaboratively lead a specific exploration tangents at least as well as some official core that is busy prioritizing other important explorations. Whatever that core is I believe it will be actively involved in, and appreciate, the discussions. You already own the problem together with others owning the same problem. I think openEHR should be a platform to facilitate collective ownership of problem solving processes and solutions. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101210/9d6bfbd1/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Koray, I agree with Thomas here, Koray, but I take your point about the separation into a further layer represents added potential development complexity. I think we should expect tools to handle this in the same way that a complex development environment like Visual Studio handles various layers of application 'code' and resources within a seamless environment. You should not have to think about these separate layers during development. Your comments about 'isCoreConcept' are very interesting because I think you have touched upon an issue in semantics that we are coming across, particularly when modelling detailed clinical findings. I had been thinking about the same issue from a different angle, essentially how to cleanly model findings where the requirement might expand gradually from a Y/N response to a full blown complex structure, in different clinical contexts and over time as more detailed requirements emerge. It touches upon the crucial areas of integration with SNOMED post-coordinations and the handling of Questionnaire type structures but I think we should continue this discussion is a separate clinical thread because it is definitely not just an issue of GUI. Ian Dr Ian McNicoll office / fax? +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst,?Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 8 December 2010 14:14, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 06/12/2010 21:06, Koray Atalag wrote: For us this was a no brainer because I think ALL pure GUI stuff should go to Templates. I have explained my reasoning in a previous message but shortly archetypes and templates are all about information capture and validation (i.e. which data items, their organisation, and basic constraints for validation). Real world semantics are delegated to terminology (i.e. heart murmur IS-A symptom of heart disease or cardia is PART-OF stomach etc). I think we need to keep archetypes fairly pure and generic with large scale interoperability in mind. However templates provide all the convenience needed otherwise. I strongly believe we do_not_need another layer of modelling for GUI because referring back to my definition of clinical models, these are to do with information capture and validation... Only one problem with this reasoning: templates are often used for things other than the GUI, e.g. messages. In the future, they will end up being used for reports as well. In general, I believe the openEHR template will be an artefact defining a specific data set (including optionality where needed), and auxiliary artefacts will always be needed to connect that definition to its target technology: a specific kind of GUI form, message infrastructure or relational mapping or querying environment - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
GUI-directives/hints again (Was: Developing usable GUIs)
On 08/12/2010 14:32, Ian McNicoll wrote: Hi Koray, I agree with Thomas here, Koray, but I take your point about the separation into a further layer represents added potential development complexity. well... software engineering history would say otherwise. Where a concept is needed you have two choices: * A) mix it in with the languages architectural layers you already have * B) create a dedicated layer or component type, and possibly dedicated formalism if needed A) represents the history of large scale systems built in the 60s, 70s and 80s - unmaintainable spaghetti. B), if done right is always better. I think we should expect tools to handle this in the same way that a complex development environment like Visual Studio handles various layers of application 'code' and resources within a seamless environment. You should not have to think about these separate layers during development. exactly - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101208/71781480/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
On 08/12/2010 15:26, pablo pazos wrote: May be if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems. I think the only thing in common of those two type of template is that they reference a set of archetypes to do something. * * I would suggest that the GUI templates just reference paths found in the openEHR template. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101208/57ab6747/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
I agree with your comment, but only for v1.5 templates and archetypes. For v1.4 I think that GUI Templates must reference archetypes ids and paths. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Wed, 8 Dec 2010 15:41:11 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) On 08/12/2010 15:26, pablo pazos wrote: May be if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems. I think the only thing in common of those two type of template is that they reference a set of archetypes to do something. I would suggest that the GUI templates just reference paths found in the openEHR template. - 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/20101208/679651d3/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Pablo, In both ADL1.4 and 1.5 every path is still an archetype-based path. The proposed schema for an operational template is very similar to the XML schema of an individual archetype but obviously includes multiple aggregated archetypes and omits any nodes which are constrained out. Templates are technically identical to specialised archetypes. The difference is that specialised archetypes support templating features such as constraining out unwanted elements and aggregating archetypes. The only difference between an archetype and a template is that new content i.e. new nodes or terms cannot be added to a template. Ian Dr Ian McNicoll office / fax? +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst,?Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 8 December 2010 16:55, pablo pazos pazospablo at hotmail.com wrote: I agree with your comment, but only for v1.5 templates and archetypes. For v1.4 I think that GUI Templates must reference archetypes ids and paths. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Wed, 8 Dec 2010 15:41:11 + From: thomas.beale at oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) On 08/12/2010 15:26, pablo pazos wrote: May be if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems. I think the only thing in common of those two type of template is that they reference a set of archetypes to do something. I would suggest that the GUI templates just reference paths found in the openEHR template. - thomas ___ 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
GUI-directives/hints again (Was: Developing usable GUIs)
On 06/12/2010 10:36, Olof Torgersson wrote: 5 dec 2010 kl. 18.04 skrev Thomas Beale: Returning to the original topic of what should go into a template, I would say that this statement supports that template should not contain GUI-directives, but that such information should go into a special visualization layer? Yes. Visualisation / GUI hints could be written on a per-form basis, probably 1:1 or maybe 1:N with respect to templates, and could use archetype paths, same as in AQL to reference things. E.g. it could have statements logically like: id = some form id templates = template 1, template 2 structure = [1] = (VBOX) [1] = (HBOX) location = x = y = controls = [1] = text_and_coded_text_control(*//[diagnosis_archetype_id]/path/to/diagnosis*) [2] = etc [2] = (HBOX) controls = [1] = some_other_control(*//**[some_other_archetype_id]/**some/other[at0003]/path[at0012]*) [3] = (VBOX) etc etc I just made this up in dADL, the real thing will be in some XML format, the point is to use archetype paths, and also potentially to have a way of mapping back from archetype/template paths to locations in the visual structure. In the above, the archetype path *[diagnosis_archetype_id]/path/to/diagnosis* is at */structure[1][1]/controls[1]* in the specification structure, which is a *text_and_coded_text_control*. You might also map a complex custom built control that captures 4 or 5 commonly grouped data elements, to a non-terminal path within a template structure. Please note: I am just thinking out aloud here, and a working 'GUI hints' language / file format will no doubt look completely different. - thomas * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101206/7fa72da6/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
On Mon, 2010-12-06 at 11:56 +0100, Olof Torgersson wrote: In the openEHR case there is a specific domain and also specifications (archetypes/templates) which you make the task easier than trying to do it generally Exactly, we have some researchers here doing exactly that work. I am certain that their results will be open sourced. --Tim -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101206/fb1a5992/attachment.asc
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Olof, I agree but I think there are some directives that are actually not purely GUI directives but which say something meaningful about the underlying information. For instance Koray's directive isCoreConcept (g): This is an abstract concept; but we can say that Core Concepts are real-world entities which we can talk about their abscence (i.e. a clinical finding, a disease but not tumour grade or physical examination). The directive depicts whether a node with all its children (if any) shall be handled and repeated as a whole in an archetype (i.e. makes sense together such as a clinical finding with other attributes defining its nature). When the node and/or its children are selected, its presence information is stored in the corresponding ELEMENT node which records this (i.e. in MST Findings archetypes [Present?] node). This seems to me to represent some sort of association between a parent concept and potential children which is independent of any GUI representation. These, I believe, should be considered for inclusion within archetypes/templates. Ian Dr Ian McNicoll office / fax? +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst,?Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 6 December 2010 10:36, Olof Torgersson olof.torgersson at chalmers.se wrote: 5 dec 2010 kl. 18.04 skrev Thomas Beale: On 05/12/2010 16:49, Tim Cook wrote: I personally think it makes it simpler for everyone to think of templates as only being used for 1. slot-filling 2. removal of unneeded optional data points and 3. tightening of some leaf value constraints, nearly always coded terms. If it turns out that data node additions make sense, we will deal with it when a true need is clear. Returning to the original topic of what should go into a template, I would say that this statement supports that template should not contain GUI-directives, but that such information should go into a special visualization layer? regards Olof - thomas ATT1..txt ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
GUI-directives/hints again (Was: Developing usable GUIs)
On 03/12/2010 22:04, David Moner wrote: Thanks Thomas. I will resume the reasoning that brought us here: in some cases templates will also be shared together with archetypes, then, in my opinion, they should not incorporate GUI related stuff and be only about data constraints. I would regard this as a base assumption, and a clear separation of concerns. - thomas * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101205/338ffc43/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Tom, On Sun, 2010-12-05 at 12:28 +, Thomas Beale wrote: The current design of ADL 1.5 is that template ids will be declared in the data (since they are just like archetype ids) - see http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf So it is really about the mechanisms for sharing archetypes and templates. If specific templates are made available for sharing, then they will be used, just like archetypes. If locally produced specialised archetypes are made available for sharing, the same for them; otherwise the receiver system has to revert back to whatever archetypes and templates it can access. ... Archetypes contain slots; templates fill them and remove unwanted archetype data points (generally most of them in any given template). It is a matter for discussion whether templates should ever be allowed to add new data points the way an archetype can. Thanks for these clarifications. They are *very* important points to consider. IMHO, if templates are permitted to add to the constraints published by an archetype then it changes the basic design paradigm. Something to consider very seriously. Regards, Tim -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101205/b3aefd7c/attachment.asc
GUI-directives/hints again (Was: Developing usable GUIs)
. methodologies. These may have an influence on the directives we will likely to come up with. My 4 cents...Cheers, -koray P.S. Our developer Mr. Hong Yul Yang (also an awesome pianist!) now has a good understanding of openEHR and I think he has much to contribute to this community...he gave a good deep thought to the above implementation technologies and MVC approach before going on with GastrOS. Hong Yul I think it is now time to talk for yourself ? don?t be shy! And people don?t hesitate to ask all your hard questions... *From:*openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] *On Behalf Of *Thomas Beale *Sent:* Thursday, 2 December 2010 2:45 p.m. *To:* openehr-technical at openehr.org *Subject:* Re: GUI-directives/hints again (Was: Developing usable GUIs) On 02/12/2010 01:33, Tim Cook wrote: On Thu, 2010-12-02 at 00:50 +, Thomas Beale wrote: This is one of the most common uses of templates we are finding. So somehow knowing the possible choices somehow affects the actual code in the field you are querying? in theory no, but it could affect what you consider to be correct. If you knew there were only 3 possible codes due to a template that had been used, then you might query directly using those codes, rather than the 20,000 allowed by the archetype. I can imagine other thing, e.g. coding of fields that were just DV_TEXT in the archetype. While I still think that this is a bad idea anyway. After all; it is either free text or coded text. Pick one. I still don't understand how knowing what set was available is meaningful to the code chosen. well the user often picks whether to code or not; a quite common visual control is one that allows either to be entered. So the template might define a preferred value set of codes, while still allowing for plain text. The archetype probably only had the plain text constraint. If you have the template at hand, you could do some querying based on the knowledge of the code subset used by the template. In ADL 1.5-land, a template is just another layer of archetyping, with some extra features. I still fail to see the need. It seems to me to be a useless layer of complexity. But, I am still interested in a use case where templates are 'needed' to 'fully interpret' the data. you mean the need of having the template to interpret the data? You can undoubtedly do it without the template. But since a lot of coding is defined locally, I think it is going to turn out to be useful. This is distinct from any 'visual template' stuff, which I agree should be a distinct artefact and probably formalism. And this level is dependent on implementation choices. Only applications built using the same framework can share these templates. If an entity is going to dictate presentation options and layout then they are likely (IMO) going to do so in the context of the same framework. * *sure. This would imply yet another technology-independent formalism, if gui directive templates are also going to be portable. - thomas -- Hong Yul Yang Research Programmer Department of Computer Science The University of Auckland Office (tamaki): 731-339 Phone: +649 373 7599 x88237 http://www.cs.auckland.ac.nz/~hongyul -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101203/44c32fd4/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Dear Tim, Thank you for your response Could you please provide me with more detail about this? Would it need manual adjustment of any css/style file or would it be totally dynamic? Is it based on the templates, archetypes, or both? I am trying to summarize the answers from different contributors, so that we can have a better image of the situation when it comes to GUI generation. Best Regards Pariya MSc; PhD Candidate Department of Computing Science and Engineering Chalmers University of Technology http://www.ait.gu.se/kontaktaoss/personal/hajar-kashfi/ On Dec 1, 2010, at 10:45 AM, Tim Cook wrote: Hi Pariya, On Wed, 2010-12-01 at 09:53 +0100, Pariya Kashfi wrote: Attached to this email you may find a GUI prototype of a clinical application. The GUI includes various tabs, trees for presenting various categories of items and so on. My very specific question is Is it possible to create such GUIs applying existing tools/frameworks? I can only speak for OSHIP. But the answer is yes. Cheers, Tim -- *** Timothy Cook, MSc Project Lead - Multi-Level Healthcare Information Modeling http://www.mlhim.org LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook You may get my Public GPG key from popular keyservers or from this link http://timothywayne.cook.googlepages.com/home -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101203/b6a8e47d/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
On Fri, 2010-12-03 at 10:21 +0100, Pariya Kashfi wrote: Dear Tim, Thank you for your response Could you please provide me with more detail about this? Would it need manual adjustment of any css/style file or would it be totally dynamic? Well, you can generate dynamic UIs; but I really doubt that they are useful in any real world situation. :-) Is it based on the templates, archetypes, or both? Archetype based; with a layer of templating for local constraints. I am trying to summarize the answers from different contributors, so that we can have a better image of the situation when it comes to GUI generation. Have you considered that it would be a good idea to conform to MSCUI? --Tim -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101203/6eb49422/attachment.asc
GUI-directives/hints again (Was: Developing usable GUIs)
Hi, From your response, my understanding is that one can generate such a GUI in OSHIP, but is also needs manual adjustments to reach the ideal GUI design. I'm not sure if I understand your last phrase. Do you mean considering design guidelines while generating GUIs? Best Regards Pariya MSc; PhD Candidate Department of Computing Science and Engineering Chalmers University of Technology http://www.ait.gu.se/kontaktaoss/personal/hajar-kashfi/ On Dec 3, 2010, at 10:35 AM, Tim Cook wrote: On Fri, 2010-12-03 at 10:21 +0100, Pariya Kashfi wrote: Dear Tim, Thank you for your response Could you please provide me with more detail about this? Would it need manual adjustment of any css/style file or would it be totally dynamic? Well, you can generate dynamic UIs; but I really doubt that they are useful in any real world situation. :-) Is it based on the templates, archetypes, or both? Archetype based; with a layer of templating for local constraints. I am trying to summarize the answers from different contributors, so that we can have a better image of the situation when it comes to GUI generation. Have you considered that it would be a good idea to conform to MSCUI? --Tim -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101203/b942dd17/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
On Fri, 2010-12-03 at 10:45 +0100, Pariya Kashfi wrote: I'm not sure if I understand your last phrase. Do you mean considering design guidelines while generating GUI Yes. -Tim On Dec 3, 2010, at 10:35 AM, Tim Cook wrote: On Fri, 2010-12-03 at 10:21 +0100, Pariya Kashfi wrote: Dear Tim, Thank you for your response Could you please provide me with more detail about this? Would it need manual adjustment of any css/style file or would it be totally dynamic? Well, you can generate dynamic UIs; but I really doubt that they are useful in any real world situation. :-) Is it based on the templates, archetypes, or both? Archetype based; with a layer of templating for local constraints. I am trying to summarize the answers from different contributors, so that we can have a better image of the situation when it comes to GUI generation. Have you considered that it would be a good idea to conform to MSCUI? --Tim -- *** Timothy Cook, MSc Project Lead - Multi-Level Healthcare Information Modeling http://www.mlhim.org LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook You may get my Public GPG key from popular keyservers or from this link http://timothywayne.cook.googlepages.com/home -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101203/27289639/attachment.asc
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Tim, I do tend to agree with you that GUI generation can be useful as a startpoint, but that most real-world applications will demand much a richer GUI that will need subsequent, manual intervention. There are 2 other areas where auto-GUI generation can be useful. One is in the area of user-defined forms, a common feature in many applications. The other is in the area of requirements gathering and prototyping, either for EHR aplication development or wider standards development work. Dr Ian McNicoll office / fax? +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst,?Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 3 December 2010 09:35, Tim Cook timothywayne.cook at gmail.com wrote: On Fri, 2010-12-03 at 10:21 +0100, Pariya Kashfi wrote: Dear Tim, Thank you for your response Could you please provide me with more detail about this? Would it need manual adjustment of any css/style file or would it be totally dynamic? Well, you can generate dynamic UIs; but I really doubt that they are useful in any real world situation. ?:-) ?Is it based on the templates, archetypes, or both? Archetype based; with a layer of templating for local constraints. I am trying to summarize the answers from different contributors, so that we can have a better image of the situation when it comes to GUI generation. Have you considered that it would be a good idea to conform to MSCUI? --Tim ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Ian, I think there is a way to customize the GUI without (direct) manual manipulation. If an application can generate expressive HTML, you can do all the customization with CSS (a good web designer can make this work for us). For expressive HTML I mean, HTML code with tags, ids and classes that let you customize every aspect of the way each template/archetype node is displayed: position, size, labels, etc. This is the only way to do GUI customization for projects that generate the GUI on the fly and that are web-based. (like the Open EHR-Gen). Example: This is an inexpressive HTML: form .. a label: input type=text name=xxx ... / input type=submit .. / /form This is an expressive HTML: form id=openEHR-EHR-SECTION.soap class=SECTION div class=SECTION div class=OBSERVATION label forxxxa label:/label input type=text name=xxx ... / /div /div div class=actions input type=submit .. / /div /form Other idea is to use some CMS-like functions, like dragging and dropping generated components on different zone of a web page layout. So, each user can have its own customized GUI. We can create a couple of these layouts, based on some GUI patterns and good practices, and adjust our GUI generators to use one layout or the other to see if the page generated is usable or not. Our Open EHR-Gen Framework has some of this ideas already developed (each node in our GUI-templates have a pageZone attribute that indicates in wich zone of the web layout, this node has to be displayed). See: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: Ian.McNicoll at oceaninformatics.com Date: Fri, 3 Dec 2010 10:17:57 + Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) To: timothywayne.cook at gmail.com; openehr-technical at openehr.org Hi Tim, I do tend to agree with you that GUI generation can be useful as a startpoint, but that most real-world applications will demand much a richer GUI that will need subsequent, manual intervention. There are 2 other areas where auto-GUI generation can be useful. One is in the area of user-defined forms, a common feature in many applications. The other is in the area of requirements gathering and prototyping, either for EHR aplication development or wider standards development work. Dr Ian McNicoll office / fax +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 3 December 2010 09:35, Tim Cook timothywayne.cook at gmail.com wrote: On Fri, 2010-12-03 at 10:21 +0100, Pariya Kashfi wrote: Dear Tim, Thank you for your response Could you please provide me with more detail about this? Would it need manual adjustment of any css/style file or would it be totally dynamic? Well, you can generate dynamic UIs; but I really doubt that they are useful in any real world situation. :-) Is it based on the templates, archetypes, or both? Archetype based; with a layer of templating for local constraints. I am trying to summarize the answers from different contributors, so that we can have a better image of the situation when it comes to GUI generation. Have you considered that it would be a good idea to conform to MSCUI? --Tim ___ 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101203/497f114b/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
On 03/12/2010 21:01, David Moner wrote: #3. The templates you use should only restrict data entry. It should not filter existing data of the same structure. If it does; there goes interoperability. Along with the entire premise for the use of and purpose of archetypes. Interesting... If templates are only used for data entry and not for data reading and revision that should be stated clearly for all developers, since I think it is not said anywhere at the specifications, the web or the wiki. Every developer should know that (coming back to the topic of this thread) if they hand-code a visualization template all that work is only useful for the data generated at their own system and not for the data from an external one, even if it is using the same archetypes. the general idea has always been that data can always be interpreted by a receiver using just the archetypes declared in the data. I believe this will continue to be a reliable assumption into the future. However, with the new style templates, which are essentially just archetypes, it may be that templates will be shared quite often as well, since the computing machinery that can deal with archetypes will be able to deal with ADL 1.5 templates as well (with only very minor upgrades from today, since we are talking about operational templates, which are essentially big archetypes). This is not going to add much information, since the information structures themselves (i.e. the compositional hierarchy of Composition, Sections, Entries etc) will reflect the structure of the template that was used. But if the receiver wants to validate the received data against the template, which is likely to include a) numerous removed optional items and b) further constrained coded text fields, then it will need the template. Note that the data as received must be definition already be valid with respect to the implicated archetypes, and if the receiver is interested in what the template says, then it means they probably have some agreement with the sender institution about using their templates. This will almost certainly happen with nationally standardised templates for referrals, discharge summaries and so on. In summary: displaying and using the data with just the archetypes used to build it will be fine, since the data will reflect accurately the removed optional items, reduced terminology choices etc. Any site wanting to do processing against the template will undoubtedly be in some kind of communication with the publisher of the template. - thomas * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101203/35747363/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Thanks Thomas. I will resume the reasoning that brought us here: in some cases templates will also be shared together with archetypes, then, in my opinion, they should not incorporate GUI related stuff and be only about data constraints. David 2010/12/3, Thomas Beale thomas.beale at oceaninformatics.com: On 03/12/2010 21:01, David Moner wrote: #3. The templates you use should only restrict data entry. It should not filter existing data of the same structure. If it does; there goes interoperability. Along with the entire premise for the use of and purpose of archetypes. Interesting... If templates are only used for data entry and not for data reading and revision that should be stated clearly for all developers, since I think it is not said anywhere at the specifications, the web or the wiki. Every developer should know that (coming back to the topic of this thread) if they hand-code a visualization template all that work is only useful for the data generated at their own system and not for the data from an external one, even if it is using the same archetypes. the general idea has always been that data can always be interpreted by a receiver using just the archetypes declared in the data. I believe this will continue to be a reliable assumption into the future. However, with the new style templates, which are essentially just archetypes, it may be that templates will be shared quite often as well, since the computing machinery that can deal with archetypes will be able to deal with ADL 1.5 templates as well (with only very minor upgrades from today, since we are talking about operational templates, which are essentially big archetypes). This is not going to add much information, since the information structures themselves (i.e. the compositional hierarchy of Composition, Sections, Entries etc) will reflect the structure of the template that was used. But if the receiver wants to validate the received data against the template, which is likely to include a) numerous removed optional items and b) further constrained coded text fields, then it will need the template. Note that the data as received must be definition already be valid with respect to the implicated archetypes, and if the receiver is interested in what the template says, then it means they probably have some agreement with the sender institution about using their templates. This will almost certainly happen with nationally standardised templates for referrals, discharge summaries and so on. In summary: displaying and using the data with just the archetypes used to build it will be fine, since the data will reflect accurately the removed optional items, reduced terminology choices etc. Any site wanting to do processing against the template will undoubtedly be in some kind of communication with the publisher of the template. - thomas * * -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a)
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Tom, On Fri, 2010-12-03 at 21:48 +, Thomas Beale wrote: the general idea has always been that data can always be interpreted by a receiver using just the archetypes declared in the data. I believe this will continue to be a reliable assumption into the future. So this begs the question. Do you think that there is a possibility that it will NOT continue to be a reliable assumption? However, with the new style templates, which are essentially just archetypes, it may be that templates will be shared quite often as well, since the computing machinery that can deal with archetypes will be able to deal with ADL 1.5 templates as well (with only very minor upgrades from today, since we are talking about operational templates, which are essentially big archetypes). So in a paragraph or less can you explain the difference between templates and simply constructing archetypes that use slots for extendability? This is not going to add much information, since the information structures themselves (i.e. the compositional hierarchy of Composition, Sections, Entries etc) will reflect the structure of the template that was used. But if the receiver wants to validate the received data against the template, But if the data validates against the archetype(s) (and therefore the reference model) there is no need to validate against templates. and if the receiver is interested in what the template says, then it means they probably have some agreement with the sender institution about using their templates. Correct. So this is not a technical issue at all. It is a socio-political issue. This will almost certainly happen with nationally standardised templates for referrals, discharge summaries and so on. Makes sense. In summary: displaying and using the data with just the archetypes used to build it will be fine, since the data will reflect accurately the removed optional items, reduced terminology choices etc. Actually the data will reflect the 'chosen' option(s). It is a historical artifact. Any site wanting to do processing against the template will undoubtedly be in some kind of communication with the publisher of the template. Right; and otherwise the data is still valid against the archetype and should be valid in any conforming application. Since my original question was asking for a use case where templates were required to fully interpret the data. Based on this assertion: On Wed, 2010-12-01 at 23:04 +0100, David Moner wrote: This specific use further constrains archetypes and these kind of structural templates should be also shared as the archetypes themselves since they will be needed to fully interpret the data. David and I agree that GUI directives have no place in structural definitions. Therefore, templates should not filter out existing (valid) data. At least I think that is what he is saying. But the point I am making is that templates do not have to be shared in order to interpret the data. Again, the only information a template can add is what particular subsets were available at the time a specific entry was chosen. I simply do not see a purpose for this 'requirement'. The data has been entered. It is now part of a historical record. Since the archetype describes the data model of the concept as a set of constraints against the reference model. That is all the validation required. Again, if I am missing something I am very interested in what it is. Thanks, Tim -- *** Timothy Cook, MSc Project Lead - Multi-Level Healthcare Information Modeling http://www.mlhim.org LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook You may get my Public GPG key from popular keyservers or from this link http://timothywayne.cook.googlepages.com/home -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101203/870bf0b7/attachment.asc
GUI-directives/hints again (Was: Developing usable GUIs)
I definitely agree with this separation into what you call structural and visualization templates. It would be really nice if the structural ones became a reality and were implemented into for instance the Java reference implementation. These were almost finished a couple of years ago and seem to still be almost finished. Then one could use these as the basis for looking into ways of doing the visualization templates. This would be cleaner then having many different variations on the structural templates with different kinds of hints etc. Olof Torgersson --- Olof Torgersson Associate Professor Department of Applied Information Technology Chalmers University of Technology and G?teborg University SE-412 96 G?teborg, Sweden email: oloft at chalmers.semailto:oloft at chalmers.se phone: +46 31 772 54 06 1 dec 2010 kl. 23.04 skrev David Moner: We had a similar discussion at the EN13606 web page. These are the conclussions I got. We should distinguish two types of templates: - Structural templates (specific use). Artefacts that constrain archetypes for specific uses or aggregate them in order to build more complex structures. These are the current openEHR templates. - Visualization templates (local use). These are a new idea. Local templates are just for visualization configuration (for example, positioning of the elements, definition of the size of a field, selection of a visual representation for a class or selection of the interface language). The important here is to distinguish ?specific use? from ?local use?. In my mind, a specific use is to define a use case where only a part of the archetypes or several archetypes are used. This is related to data structures. For example, to keep only the part of the blood pressure archetype that is important for the Primary Care measurement of vital signs. This specific use further constrains archetypes and these kind of structural templates should be also shared as the archetypes themselves since they will be needed to fully interpret the data. On the other hand, a local use is when you define constraints that are only useful for your own use or specific system. This is related to GUIs. These visualization templates are not meant to be shared outside your institution. ADL 1.5 is enough for defining the structural templates. Visualization templates needs something else to be defined. I would not recommend the use of those GUI-directives mixed with the structural templates, but to define a new level (maybe a specific model) for them. As some of you said, maybe these visualization or local templates do not need to be a part of standardized architecture since they are local implementations, but I think that it is possible to design a kind of common framework to deal with them together with archetypes and structural templates. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.eshttp://www.ibime.upv.es/ Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) ATT1..txt -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101202/7126e74c/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
On 02/12/2010 01:33, Tim Cook wrote: On Thu, 2010-12-02 at 00:50 +, Thomas Beale wrote: This is one of the most common uses of templates we are finding. So somehow knowing the possible choices somehow affects the actual code in the field you are querying? in theory no, but it could affect what you consider to be correct. If you knew there were only 3 possible codes due to a template that had been used, then you might query directly using those codes, rather than the 20,000 allowed by the archetype. I can imagine other thing, e.g. coding of fields that were just DV_TEXT in the archetype. While I still think that this is a bad idea anyway. After all; it is either free text or coded text. Pick one. I still don't understand how knowing what set was available is meaningful to the code chosen. well the user often picks whether to code or not; a quite common visual control is one that allows either to be entered. So the template might define a preferred value set of codes, while still allowing for plain text. The archetype probably only had the plain text constraint. If you have the template at hand, you could do some querying based on the knowledge of the code subset used by the template. In ADL 1.5-land, a template is just another layer of archetyping, with some extra features. I still fail to see the need. It seems to me to be a useless layer of complexity. But, I am still interested in a use case where templates are 'needed' to 'fully interpret' the data. you mean the need of having the template to interpret the data? You can undoubtedly do it without the template. But since a lot of coding is defined locally, I think it is going to turn out to be useful. This is distinct from any 'visual template' stuff, which I agree should be a distinct artefact and probably formalism. And this level is dependent on implementation choices. Only applications built using the same framework can share these templates. If an entity is going to dictate presentation options and layout then they are likely (IMO) going to do so in the context of the same framework. * * sure. This would imply yet another technology-independent formalism, if gui directive templates are also going to be portable. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101202/675fc250/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi All, late to respond but here are a few thoughts: - While having ?another layer? of modelling to handle presentation I think we already have enough of those layers. I believe the common sense of doing this will be to sort out the GUI Directives stuff we all have come up with and do a careful analysis (led by the core team of course). Decide which ones are ?universal? and which ones are data-set specific. Then like annotations in templates invent new optional keywords to accommodate these. The operational template will then contain everything an application would need to function. - I strongly believe that the presentation information should not be separated from data-set definitions ? templates. As archetypes and templates are designed to handle ?change? this means that the model will be on constant change so maintaining two models ? kind of shadows of each other does not make sense to me. Perhaps not so good design from a puristic point of view ;) - I am also pretty sure that with a handful of those GUI directives we can cover %80 of all presentation requirements in any clinical domain ? we?ll worry about the rest later on. So it may well be the case that some of these directives may become concrete and be part of the specifications ? which will boost consistency among different implementations. - I also think while thinking on these issues we should also have a look at other facades of GUI ? such as implementation technologies, Web/client forms and MVC etc. methodologies. These may have an influence on the directives we will likely to come up with. My 4 cents...Cheers, -koray P.S. Our developer Mr. Hong Yul Yang (also an awesome pianist!) now has a good understanding of openEHR and I think he has much to contribute to this community...he gave a good deep thought to the above implementation technologies and MVC approach before going on with GastrOS. Hong Yul I think it is now time to talk for yourself ? don?t be shy! And people don?t hesitate to ask all your hard questions... From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale Sent: Thursday, 2 December 2010 2:45 p.m. To: openehr-technical at openehr.org Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) On 02/12/2010 01:33, Tim Cook wrote: On Thu, 2010-12-02 at 00:50 +, Thomas Beale wrote: This is one of the most common uses of templates we are finding. So somehow knowing the possible choices somehow affects the actual code in the field you are querying? in theory no, but it could affect what you consider to be correct. If you knew there were only 3 possible codes due to a template that had been used, then you might query directly using those codes, rather than the 20,000 allowed by the archetype. I can imagine other thing, e.g. coding of fields that were just DV_TEXT in the archetype. While I still think that this is a bad idea anyway. After all; it is either free text or coded text. Pick one. I still don't understand how knowing what set was available is meaningful to the code chosen. well the user often picks whether to code or not; a quite common visual control is one that allows either to be entered. So the template might define a preferred value set of codes, while still allowing for plain text. The archetype probably only had the plain text constraint. If you have the template at hand, you could do some querying based on the knowledge of the code subset used by the template. In ADL 1.5-land, a template is just another layer of archetyping, with some extra features. I still fail to see the need. It seems to me to be a useless layer of complexity. But, I am still interested in a use case where templates are 'needed' to 'fully interpret' the data. you mean the need of having the template to interpret the data? You can undoubtedly do it without the template. But since a lot of coding is defined locally, I think it is going to turn out to be useful. This is distinct from any 'visual template' stuff, which I agree should be a distinct artefact and probably formalism. And this level is dependent on implementation choices. Only applications built using the same framework can share these templates. If an entity is going to dictate presentation options and layout then they are likely (IMO) going to do so in the context of the same framework. sure. This would imply yet another technology-independent formalism, if gui directive templates are also going to be portable. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101202/d9a7e147/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Erik, great idea. I have created this page: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates With a short description of our templates and how they are used in the framework -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Wed, 1 Dec 2010 13:24:20 +0100 Subject: GUI-directives/hints again (Was: Developing usable GUIs) From: erik.sundv...@liu.se To: openehr-technical at openehr.org CC: lincoln.moura at zilics.com.br; fabiane.nardon at zilics.com.br Hi All! There was a related discussion regarding GUI-directives/hints around june 2008, that I tried to summarize in the post http://www.openehr.org/mailarchives/openehr-technical/msg03755.html As you will see that post is somewhere in the middle of the thread, so you can find other interesting things before and after that post in the archives. Now, if I understand things correctly there is now implementatin experience from at least three projects regarding GUI-hints/directives (please add more if you know any): - Zilics (http://www.openehr.org/mailarchives/openehr-technical/msg03767.html)- GastrOs Endoscopy Application by Koray Atalag et.al. - Open EHR-Gen by Pablo Pazos et.al. What about trying to formalize some recommendations based on this experience, and perhaps even write a piece of specification draft that fits the new ADL 1.5 thinking regarding templates and archetypes. Would it be possible for anybody from any of the three projects to start a wiki page to describe your GUI-directives/hints and then we could compare them all and get a discussion going on the list possibly followed by some community driven development of a draft specification to try out. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 ___ 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/20101202/cf288cb9/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
2010/12/2, Tim Cook Hmmm,I am very interested in hearing about a use case where these templates are 'needed' to 'fully interpret' the data. Thanks, Tim Maybe I do not have the knowledge to give a valid clinical example but it is reasonable to think that constraining an archetype in the way a template does can influence the interpretation of the data. Imagine you have a set of archetypes and you define a template constraining some items to not allowed. You use that template to fill some data and then you require the collaboration of a physician from an external organisation. You share the archetypes but not the template. And then the other physician fills some more data (including the one you marked as not allowed) and returns it to you. There is the problem, when you revise the data using again your own template you will never see part of the new data and that can affect your interpretation of it. That's why structural templates must be also shared in some cases. -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a)
GUI-directives/hints again (Was: Developing usable GUIs)
Hi David, Thanks for the reply. On Thu, 2010-12-02 at 22:54 +0100, David Moner wrote: Maybe I do not have the knowledge to give a valid clinical example but it is reasonable to think that constraining an archetype in the way a template does can influence the interpretation of the data. What is reasonable is subjective; but okay. Imagine you have a set of archetypes and you define a template constraining some items to not allowed. Okay. You use that template to fill some data and then you require the collaboration of a physician from an external organisation. You share the archetypes but not the template. And then the other physician fills some more data (including the one you marked as not allowed) and returns it to you. Okay. There is the problem, when you revise the data using again your own template you will never see part of the new data and that can affect your interpretation of it. It that *is* a problem then == Bad application design. That's why structural templates must be also shared in some cases. #1. You do not revise data in a health record. You version it with additional information. #2. Any well designed archetype / template combination is going to use the same 'data structure'. Irregardless of the available options. #3. The templates you use should only restrict data entry. It should not filter existing data of the same structure. If it does; there goes interoperability. Along with the entire premise for the use of and purpose of archetypes. --Tim -- *** Timothy Cook, MSc Project Lead - Multi-Level Healthcare Information Modeling http://www.mlhim.org LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook You may get my Public GPG key from popular keyservers or from this link http://timothywayne.cook.googlepages.com/home -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101202/ac36e9d1/attachment.asc
GUI-directives/hints again (Was: Developing usable GUIs)
There's also an opensource project called EHRFlex, which is an archetype-based clinical registry system (EHR) independent of a particular reference model. It uses clinical archetypes as guidelines for the automatic generation of web interfaces, oriented to a clinical use and data introduction. Currently only supports ISO/CEN EN13606 archetypes (but could be extended to work with archetypes of any other reference model) and doesn't support templates yet here is the sourceforge website http://ehrflex.sourceforge.net/ 2010/12/1 Erik Sundvall erik.sundvall at liu.se: Hi All! There was a related discussion regarding GUI-directives/hints around june 2008, that I tried to summarize in the post ?http://www.openehr.org/mailarchives/openehr-technical/msg03755.html As you will see that post is somewhere in the middle of the thread, so you can find other interesting things before and after that post in the archives. Now, if I understand things correctly there is now implementatin experience from at least three projects regarding GUI-hints/directives (please add more if you know any): - Zilics (http://www.openehr.org/mailarchives/openehr-technical/msg03767.html) -?GastrOs?Endoscopy Application by Koray Atalag et.al. -?Open EHR-Gen by?Pablo?Pazos et.al. What about trying to formalize some recommendations based on this experience, and perhaps even write a piece of specification draft that fits the new ADL 1.5 thinking regarding templates and archetypes. Would it be possible for anybody from any of the three projects to start a wiki page to describe your GUI-directives/hints and then we could compare them all and get a discussion going on the list possibly followed by some community driven development of a draft specification to try out. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
GUI-directives/hints again (Was: Developing usable GUIs)
Thanks Eric, This is an excellent suggestion. With respect to ADL 1.5, the operational template is, I think, the key artefact. It is the 'close to run-time' data definition, and can act as the start point for a great deal of downstream tooling support. It would be interesting t know how readily other local template-based openEHR projects can generate an operational template, since this not only gives a pivot oint for GUI directives etc but makes it possible to switch back-end persistence very easily. Ian Ian McNicoll office / fax? +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst,?Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 1 December 2010 12:24, Erik Sundvall erik.sundvall at liu.se wrote: Hi All! There was a related discussion regarding GUI-directives/hints around june 2008, that I tried to summarize in the post ?http://www.openehr.org/mailarchives/openehr-technical/msg03755.html As you will see that post is somewhere in the middle of the thread, so you can find other interesting things before and after that post in the archives. Now, if I understand things correctly there is now implementatin experience from at least three projects regarding GUI-hints/directives (please add more if you know any): - Zilics (http://www.openehr.org/mailarchives/openehr-technical/msg03767.html) -?GastrOs?Endoscopy Application by Koray Atalag et.al. -?Open EHR-Gen by?Pablo?Pazos et.al. What about trying to formalize some recommendations based on this experience, and perhaps even write a piece of specification draft that fits the new ADL 1.5 thinking regarding templates and archetypes. Would it be possible for anybody from any of the three projects to start a wiki page to describe your GUI-directives/hints and then we could compare them all and get a discussion going on the list possibly followed by some community driven development of a draft specification to try out. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
GUI-directives/hints again (Was: Developing usable GUIs)
Hi, When it comes to templates, what I would like to see is that they are finalized and become a part of standard implementations such as the Java reference model. This is something I've been waiting for since I first viewed this list a couple of years ago. Then, as a next step one could start discussing various extensions, directives etc. Regards Olof Torgersson 1 dec 2010 kl. 13.24 skrev Erik Sundvall: Hi All! There was a related discussion regarding GUI-directives/hints around june 2008, that I tried to summarize in the post http://www.openehr.org/mailarchives/openehr-technical/msg03755.html As you will see that post is somewhere in the middle of the thread, so you can find other interesting things before and after that post in the archives. Now, if I understand things correctly there is now implementatin experience from at least three projects regarding GUI-hints/directives (please add more if you know any): - Zilics (http://www.openehr.org/mailarchives/openehr-technical/msg03767.html) - GastrOs Endoscopy Application by Koray Atalag et.alhttp://et.al/. - Open EHR-Gen by Pablo Pazos et.alhttp://et.al/. What about trying to formalize some recommendations based on this experience, and perhaps even write a piece of specification draft that fits the new ADL 1.5 thinking regarding templates and archetypes. Would it be possible for anybody from any of the three projects to start a wiki page to describe your GUI-directives/hints and then we could compare them all and get a discussion going on the list possibly followed by some community driven development of a draft specification to try out. Best regards, Erik Sundvall erik.sundvall at liu.semailto:erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 ATT1..txt -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101201/0c84a4fa/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Olof, I agree this is a significant missing piece of the reference model and I am not sure how close the overall ADL 1.5 spec is to being finalised but the operational template definition appears to be very stable and can act as a reference point for coalescing various local template implementations and tooling developments. Thomas has already added ADL1.5 support to the ADL Workbench and the specs seem to me to be stable enough to start implementation in Java. I think the issue is lack of time/resource, rather than immaturity of the specifications - it would be interesting to get Rong's take on this but I suspect he implemented a great deal of the current Java model prior to a stable RM being specified. Indeed I would only expect a truly stable specification to emerge after some implementation experience. IMO most real-world implementations which strive for interoperability and maximally-defined archetypes will almost all work via operational templates for validation, code -generation GUI integration. I don't think we have to wait for the full ratification of ADL1.5 and template spec to start doing interesting things in downstream support, assuming that the opt definition is pretty stable. The issues of extra directives and extensions are important at this stage as arguably some should be supported in the operational template, as I discussed above. Ian Dr Ian McNicoll office / fax? +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst,?Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 1 December 2010 17:19, Olof Torgersson olof.torgersson at chalmers.se wrote: Hi, When it comes to templates, what I would like to see is that they are finalized and become a part of standard implementations such as the Java reference model. This is something I've been waiting for since I first viewed this list a couple of years ago. Then, as a next step one could start discussing various extensions, directives etc. Regards Olof Torgersson 1 dec 2010 kl. 13.24 skrev Erik Sundvall: Hi All! There was a related discussion regarding GUI-directives/hints around june 2008, that I tried to summarize in the post ?http://www.openehr.org/mailarchives/openehr-technical/msg03755.html As you will see that post is somewhere in the middle of the thread, so you can find other interesting things before and after that post in the archives. Now, if I understand things correctly there is now implementatin experience from at least three projects regarding GUI-hints/directives (please add more if you know any): - Zilics (http://www.openehr.org/mailarchives/openehr-technical/msg03767.html) -?GastrOs?Endoscopy Application by Koray Atalag et.al. -?Open EHR-Gen by?Pablo?Pazos et.al. What about trying to formalize some recommendations based on this experience, and perhaps even write a piece of specification draft that fits the new ADL 1.5 thinking regarding templates and archetypes. Would it be possible for anybody from any of the three projects to start a wiki page to describe your GUI-directives/hints and then we could compare them all and get a discussion going on the list possibly followed by some community driven development of a draft specification to try out. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 ATT1..txt ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
GUI-directives/hints again (Was: Developing usable GUIs)
IMO templates are an implementation specific issue and should not be part of the reference model. Archetypes that express a concept as a maximal dataset are sufficient for interoperability. Local templates are just that; local templates. Certain implementations may share templates between applications but I dare say any attempt to 'standard' across implementations is wheel-spinning. If people are expecting magic pop-out-of-the-box applications then they are taking something mind-altering. :-) My 2 cents, Tim On Wed, 2010-12-01 at 18:08 +, Ian McNicoll wrote: Hi Olof, I agree this is a significant missing piece of the reference model and I am not sure how close the overall ADL 1.5 spec is to being finalised but the operational template definition appears to be very stable and can act as a reference point for coalescing various local template implementations and tooling developments. Thomas has already added ADL1.5 support to the ADL Workbench and the specs seem to me to be stable enough to start implementation in Java. I think the issue is lack of time/resource, rather than immaturity of the specifications - it would be interesting to get Rong's take on this but I suspect he implemented a great deal of the current Java model prior to a stable RM being specified. Indeed I would only expect a truly stable specification to emerge after some implementation experience. IMO most real-world implementations which strive for interoperability and maximally-defined archetypes will almost all work via operational templates for validation, code -generation GUI integration. I don't think we have to wait for the full ratification of ADL1.5 and template spec to start doing interesting things in downstream support, assuming that the opt definition is pretty stable. The issues of extra directives and extensions are important at this stage as arguably some should be supported in the operational template, as I discussed above. Ian Dr Ian McNicoll office / fax +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 1 December 2010 17:19, Olof Torgersson olof.torgersson at chalmers.se wrote: Hi, When it comes to templates, what I would like to see is that they are finalized and become a part of standard implementations such as the Java reference model. This is something I've been waiting for since I first viewed this list a couple of years ago. Then, as a next step one could start discussing various extensions, directives etc. Regards Olof Torgersson 1 dec 2010 kl. 13.24 skrev Erik Sundvall: Hi All! There was a related discussion regarding GUI-directives/hints around june 2008, that I tried to summarize in the post http://www.openehr.org/mailarchives/openehr-technical/msg03755.html As you will see that post is somewhere in the middle of the thread, so you can find other interesting things before and after that post in the archives. Now, if I understand things correctly there is now implementatin experience from at least three projects regarding GUI-hints/directives (please add more if you know any): - Zilics (http://www.openehr.org/mailarchives/openehr-technical/msg03767.html) - GastrOs Endoscopy Application by Koray Atalag et.al. - Open EHR-Gen by Pablo Pazos et.al. What about trying to formalize some recommendations based on this experience, and perhaps even write a piece of specification draft that fits the new ADL 1.5 thinking regarding templates and archetypes. Would it be possible for anybody from any of the three projects to start a wiki page to describe your GUI-directives/hints and then we could compare them all and get a discussion going on the list possibly followed by some community driven development of a draft specification to try out. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 ATT1..txt ___ 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 -- *** Timothy Cook, MSc Project Lead - Multi-Level Healthcare Information Modeling http://www.mlhim.org LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook You may get my Public GPG key from popular keyservers or from this link
GUI-directives/hints again (Was: Developing usable GUIs)
I am happy to read this opinion and I do fully agree on this. This makes it possible to use templates for any purpose desired. I already had thought of some template enrichments which work with CSS. Now that there is template parsing software in Java, I am thinking of further developing/implementing it. Next step will be a repository with archetyped controls, like a GUI building developing tool, it even could be an eclipse or visual studio plugin, or write an own development environment, and so enabling a drag and drop development tool for people close to the medical professions. The templates could be the base of a Windows-executable GUI, or Mono, or Java, or PHP, or Javascript/HTML (AJAX), a client application that changes, depending on the template loaded. It is all a matter of just work to do. Maybe I am jumping too many steps in one time, but something like that is my bit further goal. Bert Op 1-12-2010 19:30, Tim Cook schreef: IMO templates are an implementation specific issue and should not be part of the reference model. Archetypes that express a concept as a maximal dataset are sufficient for interoperability. Local templates are just that; local templates. Certain implementations may share templates between applications but I dare say any attempt to 'standard' across implementations is wheel-spinning. If people are expecting magic pop-out-of-the-box applications then they are taking something mind-altering. :-) My 2 cents, Tim On Wed, 2010-12-01 at 18:08 +, Ian McNicoll wrote: Hi Olof, I agree this is a significant missing piece of the reference model and I am not sure how close the overall ADL 1.5 spec is to being finalised but the operational template definition appears to be very stable and can act as a reference point for coalescing various local template implementations and tooling developments. Thomas has already added ADL1.5 support to the ADL Workbench and the specs seem to me to be stable enough to start implementation in Java. I think the issue is lack of time/resource, rather than immaturity of the specifications - it would be interesting to get Rong's take on this but I suspect he implemented a great deal of the current Java model prior to a stable RM being specified. Indeed I would only expect a truly stable specification to emerge after some implementation experience. IMO most real-world implementations which strive for interoperability and maximally-defined archetypes will almost all work via operational templates for validation, code -generation GUI integration. I don't think we have to wait for the full ratification of ADL1.5 and template spec to start doing interesting things in downstream support, assuming that the opt definition is pretty stable. The issues of extra directives and extensions are important at this stage as arguably some should be supported in the operational template, as I discussed above. Ian Dr Ian McNicoll office / fax +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 1 December 2010 17:19, Olof Torgerssonolof.torgersson at chalmers.se wrote: Hi, When it comes to templates, what I would like to see is that they are finalized and become a part of standard implementations such as the Java reference model. This is something I've been waiting for since I first viewed this list a couple of years ago. Then, as a next step one could start discussing various extensions, directives etc. Regards Olof Torgersson 1 dec 2010 kl. 13.24 skrev Erik Sundvall: Hi All! There was a related discussion regarding GUI-directives/hints around june 2008, that I tried to summarize in the post http://www.openehr.org/mailarchives/openehr-technical/msg03755.html As you will see that post is somewhere in the middle of the thread, so you can find other interesting things before and after that post in the archives. Now, if I understand things correctly there is now implementatin experience from at least three projects regarding GUI-hints/directives (please add more if you know any): - Zilics (http://www.openehr.org/mailarchives/openehr-technical/msg03767.html) - GastrOs Endoscopy Application by Koray Atalag et.al. - Open EHR-Gen by Pablo Pazos et.al. What about trying to formalize some recommendations based on this experience, and perhaps even write a piece of specification draft that fits the new ADL 1.5 thinking regarding templates and archetypes. Would it be possible for anybody from any of the three projects to start a wiki page to describe your GUI-directives/hints and then we could compare them all and get a discussion going on the list possibly followed by some community driven development of a draft specification to try out.
GUI-directives/hints again (Was: Developing usable GUIs)
Yes and no... we used to think that templates would be only local, but it is now clear that governments want a way to standardise whole data-sets, which is what an (ADL 1.5) template is - effectively an archetype that grabs bits of other archetypes and puts them together to create a specific data set, e.g. mixture of data captured in a specific kind of consultation, or lab result, or a discharge summary or whatever. These templates are very likely to be standardised, and offer a much better way to do this than the current way of doing it which is generally via ad hoc XML schemas. An ADL 1.5 template can be expressed as an XSD of course, but this is a downstream tool generated schema, not a hand-designed one. Further it turns out that a lot of institutions really do want to share templates, so a shareable formalism is actually important here. The ADL 1.5 spec is moving along ;-) I agree with the 'mind-altering' comment. - thomas On 01/12/2010 18:30, Tim Cook wrote: IMO templates are an implementation specific issue and should not be part of the reference model. Archetypes that express a concept as a maximal dataset are sufficient for interoperability. Local templates are just that; local templates. Certain implementations may share templates between applications but I dare say any attempt to 'standard' across implementations is wheel-spinning. If people are expecting magic pop-out-of-the-box applications then they are taking something mind-altering. :-) My 2 cents, Tim * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101201/7d6f72a7/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Well we are pretty close with ADL 1.5, and I would expect that the Java project could safely start implementing what is in the current draft of ADL 1.5 and the Template document. So, hopefully not too many months now. - thomas On 01/12/2010 17:19, Olof Torgersson wrote: Hi, When it comes to templates, what I would like to see is that they are finalized and become a part of standard implementations such as the Java reference model. This is something I've been waiting for since I first viewed this list a couple of years ago. Then, as a next step one could start discussing various extensions, directives etc. Regards Olof Torgersson 1 dec 2010 kl. 13.24 skrev Erik Sundvall: Hi All! There was a related discussion regarding GUI-directives/hints around june 2008, that I tried to summarize in the post http://www.openehr.org/mailarchives/openehr-technical/msg03755.html As you will see that post is somewhere in the middle of the thread, so you can find other interesting things before and after that post in the archives. Now, if I understand things correctly there is now implementatin experience from at least three projects regarding GUI-hints/directives (please add more if you know any): - Zilics (http://www.openehr.org/mailarchives/openehr-technical/msg03767.html) - GastrOs Endoscopy Application by Koray Atalag et.al http://et.al/. - Open EHR-Gen by Pablo Pazos et.al http://et.al/. What about trying to formalize some recommendations based on this experience, and perhaps even write a piece of specification draft that fits the new ADL 1.5 thinking regarding templates and archetypes. Would it be possible for anybody from any of the three projects to start a wiki page to describe your GUI-directives/hints and then we could compare them all and get a discussion going on the list possibly followed by some community driven development of a draft specification to try out. Best regards, Erik Sundvall erik.sundvall at liu.se mailto:erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ http://www.imt.liu.se/%7Eerisu/ Tel: +46-13-286733 ATT1..txt ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics http://www.oceaninformatics.com/* Chair Architectural Review Board, /open/EHR Foundation http://www.openehr.org/ Honorary Research Fellow, University College London http://www.chime.ucl.ac.uk/ Chartered IT Professional Fellow, BCS, British Computer Society http://www.bcs.org.uk/ Health IT blog http://www.wolandscat.net/ * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101201/7897bb44/attachment.html -- next part -- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101201/7897bb44/attachment.jpg
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Thomas, It is not just governments who will want to use templates to define agreed minimum datasets. At present all decent attempts at interoperability are essentially project-driven and often quite local e.g. Diabetes shared care dataset, Palliative care message, Emergency care summary. The difficulty has always been to ensure that each project does not end up defining variant semantics for the same core concept as they all tend to have slightly differing end-requirements. Templates turn out to be an excellent way to allow these specific use-case datasets to be defined whilst ensuring that the underlying semantics do not end up in silos since they are expressed in the underlying archetypes. Even when semantic differences cannot be resolved, it helps to express genuine disparity within the same archetype e.g differing pain scales, as it helps to concentrate any on-going debate into the enclosed scope of a single archetype. Ian Dr Ian McNicoll office / fax? +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst,?Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 1 December 2010 18:43, Thomas Beale thomas.beale at oceaninformatics.com wrote: Yes and no... we used to think that templates would be only local, but it is now clear that governments want a way to standardise whole data-sets, which is what an (ADL 1.5) template is - effectively an archetype that grabs bits of other archetypes and puts them together to create a specific data set, e.g. mixture of data captured in a specific kind of consultation, or lab result, or a discharge summary or whatever. These templates are very likely to be standardised, and offer a much better way to do this than the current way of doing it which is generally via ad hoc XML schemas. An ADL 1.5 template can be expressed as an XSD of course, but this is a downstream tool generated schema, not a hand-designed one. Further it turns out that a lot of institutions really do want to share templates, so a shareable formalism is actually important here. The ADL 1.5 spec is moving along ;-) I agree with the 'mind-altering' comment. - thomas On 01/12/2010 18:30, Tim Cook wrote: IMO templates are an implementation specific issue and should not be part of the reference model. Archetypes that express a concept as a maximal dataset are sufficient for interoperability. Local templates are just that; local templates. Certain implementations may share templates between applications but I dare say any attempt to 'standard' across implementations is wheel-spinning. If people are expecting magic pop-out-of-the-box applications then they are taking something mind-altering. :-) My 2 cents, Tim ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
GUI-directives/hints again (Was: Developing usable GUIs)
We had a similar discussion at the EN13606 web page. These are the conclussions I got. We should distinguish two types of templates: - Structural templates (specific use). Artefacts that constrain archetypes for specific uses or aggregate them in order to build more complex structures. These are the current openEHR templates. - Visualization templates (local use). These are a new idea. Local templates are just for visualization configuration (for example, positioning of the elements, definition of the size of a field, selection of a visual representation for a class or selection of the interface language). The important here is to distinguish ?specific use? from ?local use?. In my mind, a specific use is to define a use case where only a part of the archetypes or several archetypes are used. This is related to data structures. For example, to keep only the part of the blood pressure archetype that is important for the Primary Care measurement of vital signs. This specific use further constrains archetypes and these kind of structural templates should be also shared as the archetypes themselves since they will be needed to fully interpret the data. On the other hand, a local use is when you define constraints that are only useful for your own use or specific system. This is related to GUIs. These visualization templates are not meant to be shared outside your institution. ADL 1.5 is enough for defining the structural templates. Visualization templates needs something else to be defined. I would not recommend the use of those GUI-directives mixed with the structural templates, but to define a new level (maybe a specific model) for them. As some of you said, maybe these visualization or local templates do not need to be a part of standardized architecture since they are local implementations, but I think that it is possible to design a kind of common framework to deal with them together with archetypes and structural templates. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 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/20101201/62a878f7/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
On Wed, 2010-12-01 at 23:04 +0100, David Moner wrote: The important here is to distinguish ?specific use? from ?local use?. In my mind, a specific use is to define a use case where only a part of the archetypes or several archetypes are used. This is related to data structures. For example, to keep only the part of the blood pressure archetype that is important for the Primary Care measurement of vital signs. This specific use further constrains archetypes and these kind of structural templates should be also shared as the archetypes themselves since they will be needed to fully interpret the data. Hmmm,I am very interested in hearing about a use case where these templates are 'needed' to 'fully interpret' the data. Thanks, Tim -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101201/4f8926f4/attachment.asc
GUI-directives/hints again (Was: Developing usable GUIs)
On Thu, 2010-12-02 at 00:50 +, Thomas Beale wrote: Tim, if someone designs a template that has say a more limited set of Snomed or other codes on a field than the original archetypes had, then querying the data may be enabled with the template at hand, since it would tell you what (reduced) set of code values could be possible in that field. So are you introducing some mind reading into this situation? Otherwise I cannot see any other outcome. Because what you are telling me is that it is somehow meaningful in discovering the rational for choosing a Snomed code from a set as opposed to choosing the same Snomed code from some subset. Hopefully, my healthcare provider is choosing their codes based on science. Therefore they choose the correct one either way. Of course if the correct one was subsetted out; that just equals BAD TEMPLATE. But if there is some business case for this mind reading adventure. I believe you'll need the luck of this guy http://www.youtube.com/user/failblog?blend=2ob=4#p/u/85/woCCTm5m3qY to get any real information. This is one of the most common uses of templates we are finding. So somehow knowing the possible choices somehow affects the actual code in the field you are querying? I can imagine other thing, e.g. coding of fields that were just DV_TEXT in the archetype. While I still think that this is a bad idea anyway. After all; it is either free text or coded text. Pick one. I still don't understand how knowing what set was available is meaningful to the code chosen. In ADL 1.5-land, a template is just another layer of archetyping, with some extra features. I still fail to see the need. It seems to me to be a useless layer of complexity. But, I am still interested in a use case where templates are 'needed' to 'fully interpret' the data. This is distinct from any 'visual template' stuff, which I agree should be a distinct artefact and probably formalism. And this level is dependent on implementation choices. Only applications built using the same framework can share these templates. If an entity is going to dictate presentation options and layout then they are likely (IMO) going to do so in the context of the same framework. --Tim -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101201/7d36406a/attachment.asc
