Re: Templates for application form development

Hi contributors on this, I am sorry not contributing so much, it is not my piece of cake to work on defining standards, I like better using them. So I like to express that I am very grateful for the work which is being done in this context and the way it is being done. I think that it will

Re: Templates for application form development

Hi! I have also updated the https://openehr.atlassian.net/wiki/spaces/spec/pages/175276035/Application+Data-sets wikipage to include - references to some previous GUI discussions and - Region Östergötlands current use case and initial Ethercis-OPT-introspector+Angular-based design plans

Re: Templates for application form development

Thanks Thomas, I added a paragraph about the UI generation modes at the end, I forgot to mention that yesterday. On Mon, Mar 12, 2018 at 9:40 AM, Thomas Beale wrote: > Pablo, > > Good work - I've included a reference to this doc in the original wiki > page >

Re: Templates for application form development - should probably explain our EtherCIS/QEWDjs/PulseTile stack here

ok thanks Tom T On 12 March 2018 at 13:46, Thomas Beale wrote: > Tony, > this post was very useful; I've referenced it and copied bits of it to the > wiki > page > > . > > - thomas

Re: Templates for application form development - should probably explain our EtherCIS/QEWDjs/PulseTile stack here

Tony, this post was very useful; I've referenced it and copied bits of it to the wiki page . - thomas On 18/02/2018 18:34, Tony Shannon wrote: Hi all, This might be a useful time to briefly explain why

Re: Templates for application form development

Pablo, Good work - I've included a reference to this doc in the original wiki page , and added a few ideas about how to use it. It is very close to what I was thinking of. - thomas On 12/03/2018 07:31,

Re: Templates for application form development

Hi all, I manage to translate / update part of the work we did some years ago in terms of UI definition and generation for the openEHR stack. Here is the doc, feedback is very welcome! https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe-_T9H6UMsGNkiZoU7Iw/edit?usp=sharing On Wed,

Re: Templates for application form development

Well, this sounds very good, so I can forget my babble about dependency circles, concerning this part of the specs I hope this will be in stable release very soon, because I need to have a stable definition for a project Thanks Bert Op 21 feb. 2018 3:21 p.m. schreef "Thomas Beale"

Re: Templates for application form development

On 20-02-18 20:09, Thomas Beale wrote: The terminology service also has dependencies to rm data types, only because of codephrase. Wouldn't it be possible to avoid that? Yes, there is a new class TERMINOLOGY_CODE that is used in BASE instead of CODE_PHRASE; eventually, the RM should just

Re: Templates for application form development

Jussara, Here is a copy of the paper we presented on INFOLAC 2014 https://www.slideshare.net/pablitox/generacin-automtica-de-interfaces-de-usuario-para-sistemas-de-informacin-clnicos-basados-en-una-metodologa-multinivel The presentation

Re: Templates for application form development

I didn't change my mind, I was just not precise when I said that ;) - t On 20/02/2018 23:29, A Verhees wrote: So splitting up the RM instead of making it larger would be my idea. The first is not easy to do, but the second is, and helps us avoiding further problems and avoiding

Re: Templates for application form development

> > So splitting up the RM instead of making it larger would be my idea. The > first is not easy to do, but the second is, and helps us avoiding further > problems and avoiding creating unnecessary large libraries. > > > We are not intending to make the RM any larger, not sure why you think we >

Re: Templates for application form development

My problem description was good, the solution, is not really good. In fact the metaphore of circles does not work completely in openehr. I believe it is the other way around. All higher level classes may use the datatypes, but datatypes may not use the higher level classes. So datatypes must be

Re: Templates for application form development

I must have missed new developments, I am still working with RM 1.0.3 which, I was thinking, is the production version My remarks were for that version, and for my idea, there were some inconveniences in it. But I will study the new RM, and if I find some similar inconveniences, I report

Re: Templates for application form development

On 17/02/2018 21:53, A Verhees wrote: I know Thomas, but they have dependencies to other classes in the RM. To data types, to support. that should not be the case - that's exactly what we are avoiding. If we missed something it is an error. But note - most of the RM 'Support IM' model

Re: Templates for application form development

We're still working on this somewhat , using Task Planning as the excuse to finally get it right On 20/02/2018 16:44, Diego Boscá wrote: These rules/assertions are things we can express with the AM right now,

Re: Templates for application form development

Templates have no information about user interfaces, are mainly full document data structures + semantic definitions + constraints + terminology (local and bindings). User interface information includes layout, form composition, position, size, style, etc. Clearly this is not included in current

Re: Templates for application form development

Let me look for it, haveit on a backup disk somewhere :) On Tue, Feb 20, 2018 at 9:59 AM, Jussara Macedo Rötzsch < jussara.mac...@coreconsulting.com.br> wrote: > Could we have access to that Pablo? > Regards > Jussara Rotzsch > > Em dom, 18 de fev de 2018 às 15:58, Pablo Pazos

Re: Templates for application form development

These rules/assertions are things we can express with the AM right now, right? :D El 20 feb. 2018 5:37 p. m., "Thomas Beale" escribió: > > On 19/02/2018 10:47, Pablo Pazos wrote: > >> IMO annotating templates with UI info is not a good idea. A layered >> approach is

Re: Templates for application form development

On 19/02/2018 10:47, Pablo Pazos wrote: IMO annotating templates with UI info is not a good idea. A layered approach is much cleaner and scalable, i.e. to define a new artifact on top of current templates / archetypes / RM (these are also examples of layered design). here, 'templates' means

Re: Templates for application form development

Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 19 Feb 2018, at 12:07, Thomas Beale wrote: > > > note that a key problem I want to address is that templates based on > COMPOSITIONs don't really make sense as

Re: Templates for application form development

Hi, There is NO need for an other RM. Templates (imo) describe an interface. Templates for an interface used for display only need annotations in the appropriate nodes of the Display Archetype Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On

Re: Templates for application form development

Could we have access to that Pablo? Regards Jussara Rotzsch Em dom, 18 de fev de 2018 às 15:58, Pablo Pazos escreveu: > I have a pdf spec in Spanish, this was a university project to have > platform independent GUI definitions based on opts, while creating > technology

Re: Templates for application form development

In fact David, the work is about how an interface should look like, that is interesting for GUI designers. But the discussion here is not about GUI design but about offering a technical environment to GUI designers. Bert Op 19 feb. 2018 17:57 schreef "David Moner" : I was

Re: Templates for application form development

I was reviewing that work, and I found it cited this reference. This is an old topic... H. van der Linden, T. Austin, J. Talmon, Generic screen representations for future-proof systems, is it possible? There is more to a GUI than meets the eye, Comput Methods Programs Biomed. 95 (2009) 213–226.

Re: Templates for application form development

Often Spanish is not always a big problem, let us try drag through Google translate to make it al readable Bert On 19-02-18 17:37, David Moner wrote: We also have a Final Degree Project where a student made a proposal for a Visual Template Model. It's from 2012, for ISO 13606, and also in

Re: Templates for application form development

We also have a Final Degree Project where a student made a proposal for a Visual Template Model. It's from 2012, for ISO 13606, and also in Spanish, but the main idea probably remains the same :-) I've been always in favor of having a third layer for visualization purposes that defines some of

Re: Templates for application form development

IMO annotating templates with UI info is not a good idea. A layered approach is much cleaner and scalable, i.e. to define a new artifact on top of current templates / archetypes / RM (these are also examples of layered design). Under this approach, if we have UITemplates on top of openEHR

Re: Templates for application form development

Is there a terminology with concepts we can use to annotate? Probably there is and there are more. Which one, will be the question. Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 19 Feb 2018, at 07:00, Erik Sundvall

Re: Templates for application form development

Yes, this is about two different problems 1. having extra RM structures tree be used to group RM data in different ways than the one defined for a composition, in order to use y as a data retrieval for APIs and GUI. 2. another level of definition, above OPTs, to specify GUI structures and

Re: Templates for application form development

It can be that Compositions appear in a single GUI-form (in GP applications this happens regularly), but there is still no need to to show them from a single template. That can be up to the GUI-designer, he can use HTML-features to handle one or more entries in a single GUI-view. Having the

Re: Templates for application form development

note that a key problem I want to address is that templates based on COMPOSITIONs don't really make sense as models of data retrieval/display forms - they are really only useful for data capture forms (or messages, or documents), because COMPOSITION is a container for committing data to the

Re: Templates for application form development

Hi! I agree that in many use-cases it is better to have a separate template intended for GUI/application hints overlayed on a "normal" data content definition template. (Quick experimentation may be an exception.) That is why I added "layers of templates" in my previous comment - sorry for not

Re: Templates for application form development

On 19-02-18 10:21, Diego Boscá wrote: Personally I would prefer if no visualization attributes ended up in the EHR RM, but I'm fine if we want to create an additional RM to handle visualization (and we create templates of that model that point to the EHR model) I agree on this! (again

Re: Templates for application form development

Personally I would prefer if no visualization attributes ended up in the EHR RM, but I'm fine if we want to create an additional RM to handle visualization (and we create templates of that model that point to the EHR model) 2018-02-19 10:15 GMT+01:00 Bert Verhees : > On

Re: Templates for application form development

On 18-02-18 23:09, GF wrote: Is it an idea to annotate nodes with instructions for display. Personally I think having special templates/archetypes for display is better. Templates are create per purpose, and mixing purposes in a single template does  seem good idea to me

Re: Templates for application form development

sön 18 feb. 2018 kl. 23:10 skrev GF : > Is it an idea to annotate nodes with instructions for display. > Yes, using (mostly shared/standardised) annotations for GUI-rendering hints in templates (or layers of templates) has been a major idea in previous GUI-related discussions in

Re: Templates for application form development

I've created a new wiki page here on this topic , with the original post contents as background. If others would like to share existing methods or ideas for formalisation of visual or other data sets, I

Re: Templates for application form development

Is it an idea to annotate nodes with instructions for display. Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 18 Feb 2018, at 15:16, Erik Sundvall wrote: > > This is an Interesting topic! > > Standardised methods for

Re: Templates for application form development

Wops, pressed send button too early. We have experimented with lforms and conversions from archetypes are really straightforward El 18 feb. 2018 10:02 p. m., "Diego Boscá" escribió: > > El 18 feb. 2018 7:58 p. m., "Pablo Pazos" > escribió: > >> I

Re: Templates for application form development

El 18 feb. 2018 7:58 p. m., "Pablo Pazos" escribió: > I have a pdf spec in Spanish, this was a university project to have > platform independent GUI definitions based on opts, while creating > technology specific GUI generators for data entry and display. I mentioned >

Re: Templates for application form development

I have a pdf spec in Spanish, this was a university project to have platform independent GUI definitions based on opts, while creating technology specific GUI generators for data entry and display. I mentioned this a while ago on the lists but catched not much attention. Need to do a little

Re: Templates for application form development - should probably explain our EtherCIS/QEWDjs/PulseTile stack here

Hi all, This might be a useful time to briefly explain why we are supporting 3 open source components in our "showcase" stack EtherCIS - open source implementation of openEHR Clinical Data Repository http://ethercis.org/ QewdJS - nodeJS based middleware for varied purposes - inc microservices

Re: Templates for application form development

Best regards Bert And sorry for the sloppy English (when reading back), on Sundays it is worse then on weekdays when I am in working mode. But I think my message is still understandable, so, have a nice Sunday-evening. ;-) Bert ___

Re: Templates for application form development

On 18-02-18 16:55, Thomas Beale wrote: On 18/02/2018 11:16, Erik Sundvall wrote: When designing this, perhaps some (2-5) existing currently popular GUI frameworks could be initial targets for output from the process, and the selection could be updated over time. Perhaps for example

Re: Templates for application form development

On 18/02/2018 11:16, Erik Sundvall wrote: When designing this, perhaps some (2-5) existing currently popular GUI frameworks could be initial targets for output from the process, and the selection could be updated over time. Perhaps for example https://angular.io/ and https://reactjs.org/ 

Re: Templates for application form development

This is an Interesting topic! Standardised methods for representing application GUI behaviour/appearance in an open vendor neutral way is one of the few still missing pieces in the openEHR ecosystem needed in order to avoid vendor lock in. Some clever choise of split point is likely fruitful

Re: Templates for application form development

On 17/02/2018 20:11, Pablo Pazos wrote: I think SET has a lot of applications, including result sets. Of course that should interior from LOCATABLE to be archetypable. I'm not sure on the types associated with the UI. I have a specification for UITenplates that includes some of that, I can

Re: Templates for application form development

Sorry for moving away from the original subject. It was old annoyance coming up when thinking about some RM issues. Maybe when having a strict separation between the common and some other parts the problems I mentioned partly disappear. Anyway, it is not yet the moment to discuss such details in

Re: Templates for application form development

I think SET has a lot of applications, including result sets. Of course that should interior from LOCATABLE to be archetypable. I'm not sure on the types associated with the UI. I have a specification for UITenplates that includes some of that, I can share it :) I'm interested in moving this

Re: Templates for application form development

I know Thomas, but they have dependencies to other classes in the RM. To data types, to support. By the way, I have never seen use for translation details except for the archetype metadata. But maybe i missed it. That is possible, if so, excuse me for this example. The terminology service also

Re: Templates for application form development

On 17/02/2018 18:06, A Verhees wrote: If it was to me to design, I would not change the RM. In fact, I think the RM has already classes which do not belong there in my opinion. I think of AuthoredResources, TranslationDetails, they belong in the AOM.  these things are generic and are in the

Re: Templates for application form development

If it was to me to design, I would not change the RM. In fact, I think the RM has already classes which do not belong there in my opinion. I think of AuthoredResources, TranslationDetails, they belong in the AOM. The RM should not be a myriad of classes used left/right in the OpenEhr system. We