Re: Templates for application form development

[Bert Verhees]

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 be a big step forwards for OpenEhr.

Best regards
Bert Verhees


On 13-03-18 00:04, Erik Sundvall wrote:

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 (See heading
"OPT form renderer needed for pilot testing of surgery process
supporting system" near the end of the page.

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 
55 (or 010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se 
 (previously lio.se 
) http://www.regionostergotland.se/cmit/
Linköping University:erik.sundv...@liu.se 
, http://www.imt.liu.se/~erisu/ 



On Mon, Mar 12, 2018 at 11:48 PM, Pablo Pazos 
> wrote:


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

,
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, Pablo Pazos wrote:

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






-- 
Thomas Beale

Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare

Management Board, Specifications Program Lead, openEHR
Foundation 
Chartered IT Professional Fellow, BCS, British Computer
Society 
Health IT blog  | Culture blog


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org


http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org






-- 
Ing. Pablo Pazos Gutiérrez

pablo.pa...@cabolabs.com 
+598 99 043 145 
skype: cabolabs

http://www.cabolabs.com 
https://cloudehrserver.com 
Subscribe to our newsletter 


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org


http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org






___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Erik Sundvall]

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 (See heading "OPT form
   renderer needed for pilot testing of surgery process supporting system"
   near the end of the page.

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se (previously lio.se)
http://www.regionostergotland.se/cmit/
Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/

On Mon, Mar 12, 2018 at 11:48 PM, Pablo Pazos 
wrote:

> 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
>> ,
>> 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, Pablo Pazos wrote:
>>
>> 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
>>
>>
>>
>> --
>> Thomas Beale
>> Principal, Ars Semantica 
>> Consultant, ABD Team, Intermountain Healthcare
>> 
>> Management Board, Specifications Program Lead, openEHR Foundation
>> 
>> Chartered IT Professional Fellow, BCS, British Computer Society
>> 
>> Health IT blog  | Culture blog
>> 
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com
> +598 99 043 145 <+598%2099%20043%20145>
> skype: cabolabs
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Pablo Pazos]

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
> ,
> 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, Pablo Pazos wrote:
>
> 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
>
>
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
> 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Tony Shannon]

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
>
> On 18/02/2018 18:34, Tony Shannon wrote:
>
> 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
> between UI & CDR
> PulseTile- frontend UX/UI framework for healthcare
>
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
> 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Thomas Beale]

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 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 between UI & CDR

PulseTile- frontend UX/UI framework for healthcare



--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Thomas Beale]

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, Pablo Pazos wrote:

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




--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Pablo Pazos]

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, Feb 21, 2018 at 12:13 PM, A Verhees  wrote:

> 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"  >:
>
>
>>
>> On 21/02/2018 13:00, Bert Verhees wrote:
>>
>>> 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 use that. If you found any
 use of CODE_PHRASE in BASE, please let us know.

>>>
>>> This is of course a good thing.
>>>
>>>
>>> But now the question, how do I know which definition to use.
>>>
>>> I always looked at this URL: http://www.openehr.org/program
>>> s/specification/workingbaseline
>>>
>>> There I found "Support", which brings me to:
>>>
>>> http://www.openehr.org/releases/RM/latest/docs/support/support.html
>>>
>>> In that, there is CODE_PHRASE still used in TERMINOLOGY_ACCESS.
>>>
>>
>> yes - we are still working on this - to find the cleanest way to separate
>> it out without breaking current code.
>>
>>
>>>
>>> Now I read that there is a new class in BASE, I found the link:
>>> http://www.openehr.org/releases/BASE/latest/docs/index
>>>
>>> And I found Terminology_Code: http://www.openehr.org/release
>>> s/BASE/latest/docs/base_types/base_types.html#_terminology_code_class
>>>
>>> Which is a real improvement, exactly what I was hoping for, it did not
>>> only remove the CODE_PHRASE from datatypes, but also TERMINOLOGY_ID class
>>> from SUPPORT
>>>
>>> It has a property/field which is named terminology_id and is of type
>>> string
>>>
>>>
>>> Is this what is going to be the new standard?
>>>
>>> And when will this be like that?
>>>
>>
>> Well it will be the new standard for BASE classes very soon. Over time,
>> we will start either replacing CODE_PHRASE in the upper models with
>> TERMINOLOGY_CODE, or possibly adding some sort of mapping / conversion
>> logic. But we'll only do that based on input from implementers - we need to
>> find a way to update the models without breaking existing systems.
>>
>>
>>>
>>> When looking further, I also see that there is still a TERMINOLOGY_ID
>>> class in that document which is the old support terminology which is
>>> derived from OBJECT_ID
>>>
>>> http://www.openehr.org/releases/BASE/latest/docs/base_types/
>>> base_types.html#_terminology_id_class
>>>
>>>
>>> Is this confusing, or am I missing something stupid? Am I the only
>>> person asking this kind of questions? If yes, where do others get their
>>> information from?
>>>
>>> Please help me, because, I think, this is very important.
>>>
>>
>> you should consider the classes you see in BASE today as being what will
>> be issued, unless anyone finds a problem with them. In the near future, we
>> will continue the cleanup around terminology. One reason we have not
>> cleaned it up yet is because noone in industry agrees on what standard or
>> tools to use. Noone faithfully implements CTS2 for example, except a
>> non-maintained server from Mayo (LexGrid from memory). IHTSDO did something
>> different, and FHIR did something else.  All have good and bad points, but
>> there has been no clear specification.
>>
>> I am inclined to think that the specification of the future is a kind of
>> stripped down CTS2 that gets rid of XML/XSD, and can be used with multiple
>> serialisation formats, and cleaner models, but semantically, more or less
>> the same. But we have to be practical too. Maybe the FHIR terminology
>> service will evolve in the most appropriate way; they already have the same
>> URI representation of terms as our BASE classes now have.
>>
>> All input on this welcome, as usual.
>>
>> - thomas
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 

Re: Templates for application form development

[A Verhees]

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" :

>
>
> On 21/02/2018 13:00, Bert Verhees wrote:
>
>> 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 use that. If you found any
>>> use of CODE_PHRASE in BASE, please let us know.
>>>
>>
>> This is of course a good thing.
>>
>>
>> But now the question, how do I know which definition to use.
>>
>> I always looked at this URL: http://www.openehr.org/program
>> s/specification/workingbaseline
>>
>> There I found "Support", which brings me to:
>>
>> http://www.openehr.org/releases/RM/latest/docs/support/support.html
>>
>> In that, there is CODE_PHRASE still used in TERMINOLOGY_ACCESS.
>>
>
> yes - we are still working on this - to find the cleanest way to separate
> it out without breaking current code.
>
>
>>
>> Now I read that there is a new class in BASE, I found the link:
>> http://www.openehr.org/releases/BASE/latest/docs/index
>>
>> And I found Terminology_Code: http://www.openehr.org/release
>> s/BASE/latest/docs/base_types/base_types.html#_terminology_code_class
>>
>> Which is a real improvement, exactly what I was hoping for, it did not
>> only remove the CODE_PHRASE from datatypes, but also TERMINOLOGY_ID class
>> from SUPPORT
>>
>> It has a property/field which is named terminology_id and is of type
>> string
>>
>>
>> Is this what is going to be the new standard?
>>
>> And when will this be like that?
>>
>
> Well it will be the new standard for BASE classes very soon. Over time, we
> will start either replacing CODE_PHRASE in the upper models with
> TERMINOLOGY_CODE, or possibly adding some sort of mapping / conversion
> logic. But we'll only do that based on input from implementers - we need to
> find a way to update the models without breaking existing systems.
>
>
>>
>> When looking further, I also see that there is still a TERMINOLOGY_ID
>> class in that document which is the old support terminology which is
>> derived from OBJECT_ID
>>
>> http://www.openehr.org/releases/BASE/latest/docs/base_types/
>> base_types.html#_terminology_id_class
>>
>>
>> Is this confusing, or am I missing something stupid? Am I the only person
>> asking this kind of questions? If yes, where do others get their
>> information from?
>>
>> Please help me, because, I think, this is very important.
>>
>
> you should consider the classes you see in BASE today as being what will
> be issued, unless anyone finds a problem with them. In the near future, we
> will continue the cleanup around terminology. One reason we have not
> cleaned it up yet is because noone in industry agrees on what standard or
> tools to use. Noone faithfully implements CTS2 for example, except a
> non-maintained server from Mayo (LexGrid from memory). IHTSDO did something
> different, and FHIR did something else.  All have good and bad points, but
> there has been no clear specification.
>
> I am inclined to think that the specification of the future is a kind of
> stripped down CTS2 that gets rid of XML/XSD, and can be used with multiple
> serialisation formats, and cleaner models, but semantically, more or less
> the same. But we have to be practical too. Maybe the FHIR terminology
> service will evolve in the most appropriate way; they already have the same
> URI representation of terms as our BASE classes now have.
>
> All input on this welcome, as usual.
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Bert Verhees]

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 use that. If 
you found any use of CODE_PHRASE in BASE, please let us know.


This is of course a good thing.


But now the question, how do I know which definition to use.

I always looked at this URL: 
http://www.openehr.org/programs/specification/workingbaseline


There I found "Support", which brings me to:

http://www.openehr.org/releases/RM/latest/docs/support/support.html

In that, there is CODE_PHRASE still used in TERMINOLOGY_ACCESS.


Now I read that there is a new class in BASE, I found the link: 
http://www.openehr.org/releases/BASE/latest/docs/index


And I found Terminology_Code: 
http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_terminology_code_class


Which is a real improvement, exactly what I was hoping for, it did not 
only remove the CODE_PHRASE from datatypes, but also TERMINOLOGY_ID 
class from SUPPORT


It has a property/field which is named terminology_id and is of type string


Is this what is going to be the new standard?

And when will this be like that?


When looking further, I also see that there is still a TERMINOLOGY_ID 
class in that document which is the old support terminology which is 
derived from OBJECT_ID


http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_terminology_id_class


Is this confusing, or am I missing something stupid? Am I the only 
person asking this kind of questions? If yes, where do others get their 
information from?


Please help me, because, I think, this is very important.


Thanks

Bert


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Pablo Pazos]

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

http://www.sueiidiss.org/images/archivos2015/temasinfolac/22.pdf

That paper is referenced from my MEDINFO 2015 paper

https://books.google.com.uy/books?id=OmZrCgAAQBAJ=PA49=PA49=Generaci%C3%B3n+autom%C3%A1tica+de+interfaces+de+usuario+para+sistemas+de+informaci%C3%B3n+cl%C3%ADnicos+basados+en+la+metodolog%C3%ADa+multinivel=bl=GAd8sfgJuz=UK5rAgO1xrSUEnrUPpWPxDdSJ-E=en=X=0ahUKEwjh_vPPoLbZAhWimeAKHaexDkoQ6AEIMDAB#v=onepage=Generaci%C3%B3n%20autom%C3%A1tica%20de%20interfaces%20de%20usuario%20para%20sistemas%20de%20informaci%C3%B3n%20cl%C3%ADnicos%20basados%20en%20la%20metodolog%C3%ADa%20multinivel=false


All are also here
http://independent.academia.edu/pablopazos



Since then, I have updated the UITemplate model to use OPTs instead of
archetypes directly, added improvements and features that are not in the
initial model from the paper. The new model still needs work, but we proven
we can use it as an abstract, generic, declarative openEHR UI definition
focused on data entry and form-oriented visualization. And that technology
specific UI generators can use it to output other declarative form UI
specifications, that dev tools / IDEs can take in order to render UIs. E.g.
from an UITemplate instance in XML,  different generators can generate XAML
(.NET UI definitions), SwiXML (Java Swing UI definitions), XHTML/HTML5 (for
web), and there are XML UI definitions also for Android and iOS that can be
generated. Basically generators are XML mappers, and knowing the
destination schema is really easy to create the maping rules between input
UITemplates and X technology UI definition.

A second level, of definition is also missing, about the rules for data
input, like "if field X has a value, show field Y". I don't think we need
to specify mandatory or cardinality constraints on the UITemplate since the
OPT already has those and the UITemplate should just define UI stuff that
is not on the referenced OPT.

I hope to have an updated & translated spec for next week.

Best,
Pablo.

On Tue, Feb 20, 2018 at 1:52 PM, Pablo Pazos 
wrote:

> Let me look for it, haveit on a backup disk somewhere :)
>
> On Tue, Feb 20, 2018 at 9:59 AM, Jussara Macedo Rötzsch  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 
>> 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 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 translation work :)
>>>
>>>
>>> On Feb 18, 2018 7:51 AM, "Thomas Beale" 
>>> wrote:
>>>
>>>
>>>
>>> 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 share it :)


>>> I think any existing UI/template specification / app modelling would be
>>> useful to share - possibly on the wiki - let me know if you need a page
>>> there.
>>>
>>> My aim would be to get closer to an IDE application building tool for
>>> clinical people to at least build a POC application that works, something
>>> like Balsamiq but with real data connections built in. Marand's EhrExplorer
>>> does some of this, and it would also be useful to extract some of the
>>> semantics of that tool into a standard specification to support this kind
>>> of thing.
>>>
>>> - thomas
>>>
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>>> lists.openehr.org
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>>> lists.openehr.org
>>
>> --
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com
> +598 99 043 145 <099%20043%20145>
> skype: cabolabs
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter 
>



-- 
Ing. Pablo Pazos Gutiérrez

Re: Templates for application form development

[Thomas Beale]

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 creating unnecessary
large libraries.


We are not intending to make the RM any larger, not sure why you
think we are.


In your first message about this proposal was something that made me 
think you were about to enlarge the RM and also to have all in a large 
pile of classes.


I quote: "Doing the above requires adding some new classes to the RM, 
or a Presentation Model part of openEHR."


I think you changed your mind now, so that is not important.



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[A Verhees]

>
> 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
> are.
>

In your first message about this proposal was something that made me think
you were about to enlarge the RM and also to have all in a large pile of
classes.

I quote: "Doing the above requires adding some new classes to the RM, or a
Presentation Model part of openEHR."

I think you changed your mind now, so that is not important.

Bert
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[A Verhees]

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 the most inner circle so
that all classes around can use datatypes. This also has an inconvenience
because of dvtext which has that dependency to higher level terminology.

So what do we do with on terminology depending datatypes? Make them part of
the terminology related software of which terminology service also will
become a part?

Or do we remove codephrase from terminology service so that terminology
service can be an inner circle of datatypes? So codephrase will then be in
the datatypes, and terminologyid should not be inherited from object_id
which else causes a conflict with support, so terminologyId would be a part
of terminology service.

Or support should be the inner most circle, then terminology and then
datatypes?

Bert

Op di 20 feb. 2018 21:19 schreef Bert Verhees :

> 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 them.
>
> This is a bit another subject, but I explain it anyway, because last
> weekend, I was not satisfied about my emails
> Please let me explain why it is an important problem to me.
>
> Maven (Java dependency tool) gets grumpy about circular library
> references, and the Golang compiler does accept circular package
> references and restricts using circular struct references.
> C++ does not accept circular class references, but can be worked around
> in a tricky way.
>
> Circular references
>
> The Dependency Rule says that source code dependencies can only point
> inwards. Nothing in an inner circle can know anything at all about
> something in an outer circle. In particular, the name of something
> declared in an outer circle must not be mentioned by the code in an
> inner circle. That includes, functions, classes. variables, or any other
> named software entity. As you move inwards the level of abstraction
> increases. The outermost circle is low level concrete detail. As you
> move inwards the software grows more abstract, and encapsulates higher
> level policies.
>
> Robert C Martin.
>
> Terminologyservice needs codephrase, and codeprase is part of the
> datatypes, dvtext (also datatype) needs terminologyservice (in
> constructor). (circular reference)
> Other datatypes, for example, dvtext also need a ready compiled
> terminologyservice and codephrase for checking the charset and language
> in the constructor
> This situation makes it impossible to separate the terminologyservice
> from the datatypes, although they have no similar abstraction level
> In OpenEhr this is solved by using an interface of terminologyService
> inside the support-part, and that would be a good solution if the
> interface did not have the codephrase also in its declarations.
> So it did not solve it the violation of the dependency rule, but it
> makes it compilable.
>
> So it is a problem, and causes dirty code to solve. The solution is
> simple. Make CodePhrase a part of TerminologyService and remove it from
> datatypes. Then all classes which need code-phrase have to link in
> terminologyservice, but terminology can be compiled independently from
> other classes
>
> The most inner circle of the dependencies should be a group
> libraries/classes which do not need each other by the route of an outer
> circle. The most inner group should be AOM, TerminologyService, EHR-RM,
> around that should be the Support, and around that should be the
> datatypes. Then there would be no problem, the datatypes can be linked
> against every library and will never cause a circular reference.
>
> Best regards
> Bert
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Bert Verhees]

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 them.


This is a bit another subject, but I explain it anyway, because last 
weekend, I was not satisfied about my emails

Please let me explain why it is an important problem to me.

Maven (Java dependency tool) gets grumpy about circular library 
references, and the Golang compiler does accept circular package 
references and restricts using circular struct references.
C++ does not accept circular class references, but can be worked around 
in a tricky way.


Circular references

The Dependency Rule says that source code dependencies can only point 
inwards. Nothing in an inner circle can know anything at all about 
something in an outer circle. In particular, the name of something 
declared in an outer circle must not be mentioned by the code in an 
inner circle. That includes, functions, classes. variables, or any other 
named software entity. As you move inwards the level of abstraction 
increases. The outermost circle is low level concrete detail. As you 
move inwards the software grows more abstract, and encapsulates higher 
level policies.


Robert C Martin.

Terminologyservice needs codephrase, and codeprase is part of the 
datatypes, dvtext (also datatype) needs terminologyservice (in 
constructor). (circular reference)
Other datatypes, for example, dvtext also need a ready compiled 
terminologyservice and codephrase for checking the charset and language 
in the constructor
This situation makes it impossible to separate the terminologyservice 
from the datatypes, although they have no similar abstraction level
In OpenEhr this is solved by using an interface of terminologyService 
inside the support-part, and that would be a good solution if the 
interface did not have the codephrase also in its declarations.
So it did not solve it the violation of the dependency rule, but it 
makes it compilable.


So it is a problem, and causes dirty code to solve. The solution is 
simple. Make CodePhrase a part of TerminologyService and remove it from 
datatypes. Then all classes which need code-phrase have to link in 
terminologyservice, but terminology can be compiled independently from 
other classes


The most inner circle of the dependencies should be a group 
libraries/classes which do not need each other by the route of an outer 
circle. The most inner group should be AOM, TerminologyService, EHR-RM, 
around that should be the Support, and around that should be the 
datatypes. Then there would be no problem, the datatypes can be linked 
against every library and will never cause a circular reference.


Best regards
Bert

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Thomas Beale]

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 moved to BASE.



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.


We think it will get used for Task Plans, and maybe GDL guides.



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 use that. If you found 
any use of CODE_PHRASE in BASE, please let us know.


This also creates a circular dependency at construction of several RM 
classes. They need the OpenEhr terminology when constructed, and the 
terminology needs the RM codephrase.


The archetype_Id is inherited from object_id, but why is that 
necessary? What is the advantage?


Not much admittedly, since OBJECT_ID is just an identifier with a 
concrete String representation, but it does mean that an OBJECT_REF can 
point to any kind of OBJECT_ID, including an ARCHETYPE_ID.




Of course it is not only design, it is also the developers, they 
create those large libraries, but they are inspired by the theoretical 
architecture-plan, and maybe they need to do that to avoid circular 
library references.


yes, as I say, there should be absolutely none of these. Any you see 
need to be reported.




There is, in my opinion a need to split the RM. Rongs did that a few 
years ago, he had an Ehr-RM and a  (was it...) common RM. A step in a 
good direction.


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 are.


- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Thomas Beale]

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, right?  :D


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Pablo Pazos]

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 openEHR templates.

BTW all those elements are part of the UITemplate model that I mentioned
before. Will try to have an english translation to share next week.

On Tue, Feb 20, 2018 at 10:58 AM, GF  wrote:

> 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 <+31%206%2020347088>
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 19 Feb 2018, at 10:29, Bert Verhees  wrote:
>
> 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 sloppy English in my previous message, this time changing the
> meaning, I changed the quote below, I am awake now, will not happen again,
> excuse me)
>
>
> 2018-02-19 10:15 GMT+01:00 Bert Verhees :
>
>> 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*d* per purpose, and mixing purposes in a
>> single template does *no**t* seem good idea to me
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Pablo Pazos]

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 
> 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 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 translation work :)
>>
>>
>> On Feb 18, 2018 7:51 AM, "Thomas Beale"  wrote:
>>
>>
>>
>> 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 share it :)
>>>
>>>
>> I think any existing UI/template specification / app modelling would be
>> useful to share - possibly on the wiki - let me know if you need a page
>> there.
>>
>> My aim would be to get closer to an IDE application building tool for
>> clinical people to at least build a POC application that works, something
>> like Balsamiq but with real data connections built in. Marand's EhrExplorer
>> does some of this, and it would also be useful to extract some of the
>> semantics of that tool into a standard specification to support this kind
>> of thing.
>>
>> - thomas
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> technical_lists.openehr.org
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> technical_lists.openehr.org
>
> --
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Diego Boscá]

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 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 pure data templates, i.e. pure RM or other data
> constructs, e.g. PROC (Task Planning) or CDS etc.
>
>
>> Under this approach, if we have UITemplates on top of openEHR Templates,
>> when we generate Operational UITemplates, that will contain UI + structure
>> (template and archetype constraints) + RM references. This would be the
>> final element to be used to feed software. but the underlying models are
>> all separated and have a specific responsibility.
>>
>
> So what I am proposing is what you are calling UITemplates (one could also
> think of DOCTemplates and MSGTemplates) - they are openEHR templates, as in
> being ADL/AOM artefacts, but based on a model of UI/presentation primitives
> that enables RM and other data elements to be embedded.
>
>
>> If we go ahead, we can add another level for workflow, defining an order
>> and conditions under which each "screen" should be displayed, like a
>> WFTemplate, having an Operational WFTemplate that will include all WF + GUI
>> + structure + RM references.
>>
>
> I think this can make sense as either another model layer, or maybe better
> as specific annotations that use FOPL-like or rule statements to define
> work flow, e.g.
>
> when /data/path1/value = "coded" then display (/ui/path5)
>
> where /data/path1 is an archetype path of the kind we are used to,
> pointing to some DV_TEXT element and /ui/path5 is a path through the UI
> template that points to a sub-form, presumably one that knows how to ask
> for a coded text.
>
> If we separate out screen workflow from screen logical layout, then we can
> re-use the latter with different workflows, reprocess it into a PDF or
> other document structure and so on.
>
>
>> We can continue adding layers :)
>>
>
> exactly right.
>
> - thomas
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Thomas Beale]

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 pure data templates, i.e. pure RM or other data 
constructs, e.g. PROC (Task Planning) or CDS etc.




Under this approach, if we have UITemplates on top of openEHR 
Templates, when we generate Operational UITemplates, that will contain 
UI + structure (template and archetype constraints) + RM references. 
This would be the final element to be used to feed software. but the 
underlying models are all separated and have a specific responsibility.


So what I am proposing is what you are calling UITemplates (one could 
also think of DOCTemplates and MSGTemplates) - they are openEHR 
templates, as in being ADL/AOM artefacts, but based on a model of 
UI/presentation primitives that enables RM and other data elements to be 
embedded.




If we go ahead, we can add another level for workflow, defining an 
order and conditions under which each "screen" should be displayed, 
like a WFTemplate, having an Operational WFTemplate that will include 
all WF + GUI + structure + RM references.


I think this can make sense as either another model layer, or maybe 
better as specific annotations that use FOPL-like or rule statements to 
define work flow, e.g.


when /data/path1/value = "coded" then display (/ui/path5)

where /data/path1 is an archetype path of the kind we are used to, 
pointing to some DV_TEXT element and /ui/path5 is a path through the UI 
template that points to a sub-form, presumably one that knows how to ask 
for a coded text.


If we separate out screen workflow from screen logical layout, then we 
can re-use the latter with different workflows, reprocess it into a PDF 
or other document structure and so on.




We can continue adding layers :)


exactly right.

- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[GF]

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 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 
> EHR. 
> 


Or any interface be it for committing, querying, display, data entry, 
documents, messages, clinical decision support interactions?
These all can be dedicated kinds of Template/Interface
> Displaying data is a different question - it may be EHR data, it may be 
> demographic data, and it may be something else entirely. So the data items we 
> want to mention in templates are mostly of ENTRY level, and will be the 
> results of queries; the relevant queries could be included in such templates. 
> 
> So the starting point for many forms won't be a COMPOSITION - it is instead a 
> different logical container that groups data that result from one or more 
> queries, into a 'use group', i.e the group of data items intended to be 
> visualised or used as a report etc.
> 
> 

Unless the COMPOSITION is the description of any interface.

> One problem today is that people trying to define screens for visual 
> applications are forced (more or less) to create templates starting with 
> COMPOSITIONs, which is incorrect; my impression is that such templates are 
> only used for data capture and that other display forms are modelled in 
> various non-standard ways, or not at all.
> 
> I think annotations (based on paths) will be useful, but I not completely 
> adequate to achieved what is needed.
> 
Why?


> - thomas
> 
> 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[GF]

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 19 Feb 2018, at 10:29, Bert Verhees  wrote:
> 
> 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 sloppy English in my previous message, this time changing the meaning, 
> I changed the quote below, I am awake now, will not happen again, excuse me)
> 
>> 
>> 2018-02-19 10:15 GMT+01:00 Bert Verhees > >:
>> 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 created per purpose, and mixing purposes in a single 
>> template does not seem good idea to me
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Jussara Macedo Rötzsch]

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 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 translation work :)
>
>
> On Feb 18, 2018 7:51 AM, "Thomas Beale"  wrote:
>
>
>
> 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 share it :)
>>
>>
> I think any existing UI/template specification / app modelling would be
> useful to share - possibly on the wiki - let me know if you need a page
> there.
>
> My aim would be to get closer to an IDE application building tool for
> clinical people to at least build a POC application that works, something
> like Balsamiq but with real data connections built in. Marand's EhrExplorer
> does some of this, and it would also be useful to extract some of the
> semantics of that tool into a standard specification to support this kind
> of thing.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[A Verhees]

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 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.
doi:10.1016/j.cmpb.2009.03.003.


2018-02-19 17:37 GMT+01:00 David Moner :

> 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 the expected behaviors and the visual aspect.
> As Erik said, this is not about reinventing what the existing UI frameworks
> can do, but to have a way of instructing them on how to show the
> information on screen.
>
> 2018-02-18 19:57 GMT+01:00 Pablo Pazos :
>
>> 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 translation work :)
>>
>>
>> On Feb 18, 2018 7:51 AM, "Thomas Beale"  wrote:
>>
>>
>>
>> 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 share it :)
>>>
>>>
>> I think any existing UI/template specification / app modelling would be
>> useful to share - possibly on the wiki - let me know if you need a page
>> there.
>>
>> My aim would be to get closer to an IDE application building tool for
>> clinical people to at least build a POC application that works, something
>> like Balsamiq but with real data connections built in. Marand's EhrExplorer
>> does some of this, and it would also be useful to extract some of the
>> semantics of that tool into a standard specification to support this kind
>> of thing.
>>
>> - thomas
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
> David Moner Cano
>
> Web: http://www.linkedin.com/in/davidmoner
> Twitter: @davidmoner
> Skype: davidmoner
>



-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-
technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[David Moner]

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.
doi:10.1016/j.cmpb.2009.03.003.


2018-02-19 17:37 GMT+01:00 David Moner :

> 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 the expected behaviors and the visual aspect.
> As Erik said, this is not about reinventing what the existing UI frameworks
> can do, but to have a way of instructing them on how to show the
> information on screen.
>
> 2018-02-18 19:57 GMT+01:00 Pablo Pazos :
>
>> 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 translation work :)
>>
>>
>> On Feb 18, 2018 7:51 AM, "Thomas Beale"  wrote:
>>
>>
>>
>> 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 share it :)
>>>
>>>
>> I think any existing UI/template specification / app modelling would be
>> useful to share - possibly on the wiki - let me know if you need a page
>> there.
>>
>> My aim would be to get closer to an IDE application building tool for
>> clinical people to at least build a POC application that works, something
>> like Balsamiq but with real data connections built in. Marand's EhrExplorer
>> does some of this, and it would also be useful to extract some of the
>> semantics of that tool into a standard specification to support this kind
>> of thing.
>>
>> - thomas
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
> David Moner Cano
>
> Web: http://www.linkedin.com/in/davidmoner
> Twitter: @davidmoner
> Skype: davidmoner
>



-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Bert Verhees]

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 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 the expected behaviors and the visual 
aspect. As Erik said, this is not about reinventing what the existing 
UI frameworks can do, but to have a way of instructing them on how to 
show the information on screen.


2018-02-18 19:57 GMT+01:00 Pablo Pazos >:


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 translation work :)


On Feb 18, 2018 7:51 AM, "Thomas Beale" > wrote:



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 share it :)


I think any existing UI/template specification / app modelling
would be useful to share - possibly on the wiki - let me know
if you need a page there.

My aim would be to get closer to an IDE application building
tool for clinical people to at least build a POC application
that works, something like Balsamiq but with real data
connections built in. Marand's EhrExplorer does some of this,
and it would also be useful to extract some of the semantics
of that tool into a standard specification to support this
kind of thing.

- thomas



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org


http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org





___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org


http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org






--
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[David Moner]

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 the expected behaviors and the visual aspect.
As Erik said, this is not about reinventing what the existing UI frameworks
can do, but to have a way of instructing them on how to show the
information on screen.

2018-02-18 19:57 GMT+01:00 Pablo Pazos :

> 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 translation work :)
>
>
> On Feb 18, 2018 7:51 AM, "Thomas Beale"  wrote:
>
>
>
> 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 share it :)
>>
>>
> I think any existing UI/template specification / app modelling would be
> useful to share - possibly on the wiki - let me know if you need a page
> there.
>
> My aim would be to get closer to an IDE application building tool for
> clinical people to at least build a POC application that works, something
> like Balsamiq but with real data connections built in. Marand's EhrExplorer
> does some of this, and it would also be useful to extract some of the
> semantics of that tool into a standard specification to support this kind
> of thing.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Pablo Pazos]

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 Templates,
when we generate Operational UITemplates, that will contain UI + structure
(template and archetype constraints) + RM references. This would be the
final element to be used to feed software. but the underlying models are
all separated and have a specific responsibility.

If we go ahead, we can add another level for workflow, defining an order
and conditions under which each "screen" should be displayed, like a
WFTemplate, having an Operational WFTemplate that will include all WF + GUI
+ structure + RM references.

We can continue adding layers :)

On Mon, Feb 19, 2018 at 10:23 AM, GF  wrote:

> 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 <+31%206%2020347088>
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 19 Feb 2018, at 07:00, Erik Sundvall  wrote:
>
>
> 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 openEHR mailing lists.
>
> //Erik
>
> (We should link to some old list posts on the topic in that wiki page Tom
> created)
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[GF]

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  wrote:
> 
> 
> 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 openEHR mailing lists. 
> 
> //Erik
> 
> (We should link to some old list posts on the topic in that wiki page Tom 
> created)
> 
> 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Pablo Pazos]

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
attributes, and maybe bindings with specific GUI technologies. This doesn't
affect current RM or change anything on the OPT model.

On Feb 19, 2018 8:08 AM, "Thomas Beale"  wrote:

>
> 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
> EHR.
>
> Displaying data is a different question - it may be EHR data, it may be
> demographic data, and it may be something else entirely. So the data items
> we want to mention in templates are mostly of ENTRY level, and will be the
> results of queries; the relevant queries could be included in such
> templates.
>
> So the starting point for many forms won't be a COMPOSITION - it is
> instead a different logical container that groups data that result from one
> or more queries, into a 'use group', i.e the group of data items intended
> to be visualised or used as a report etc.
>
> One problem today is that people trying to define screens for visual
> applications are forced (more or less) to create templates starting with
> COMPOSITIONs, which is incorrect; my impression is that such templates are
> only used for data capture and that other display forms are modelled in
> various non-standard ways, or not at all.
>
> I think annotations (based on paths) will be useful, but I not completely
> adequate to achieved what is needed.
>
> - thomas
>
> On 19/02/2018 07:49, Erik Sundvall wrote:
>
> 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 explaining in detail. So a GUI-hint-annotated template based on
> another "normal" content aggregation/constraint-focused template would be
> a way to do it. I guess the effect in a resulting operational template
> (OPT) is essentially the same no matter how many layers of templates you
> choose to work with, right? So a form/GUI-renderer based on OPTs does not
> care how you layer the design, but your maintenance headaches might be
> affected if not separating things at design time.
>
> I agree with Diego and Bert and suggest starting experimenting in the AM
> end (for example using annotations with GUI-hints in templates) and see how
> far that takes us, before possibly considering extending the RM (or
> whatever *M).
>
> Annotations do not require any changes to AM or RM, the mechanism is
> already defined in the specifications. Conventions regarding patterns or
> prefixes in annotation keys and/or annotation values will likely give
> enough to start with.
>
> A (not so very thought through yet) possible example of annotation use for
> application building is available in picture 40 (and supported by picture
> 36 in
> https://drive.google.com/file/d/1kxXeJMe0ltfLlchGA0Lm8mfOD-
> PQDLFy/view?usp=sharing
>
> //Erik
>
> mån 19 feb. 2018 kl. 10:22 skrev Bert Verhees :
>
>> 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
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>
>
>
> ___
> openEHR-technical mailing 
> listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
> 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list

Re: Templates for application form development

[Bert Verhees]

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 entries offered to the GUI-developer separated from 
the composition offers all the flexibility the GUI-developer needs.


He can show a complete composition by connecting GUI-blocks on 
client-level, he can show history-lists of medications or observations 
without composition context, what ever is desired.


Bert


On 19-02-18 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 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 EHR.


Displaying data is a different question - it may be EHR data, it may 
be demographic data, and it may be something else entirely. So the 
data items we want to mention in templates are mostly of ENTRY level, 
and will be the results of queries; the relevant queries could be 
included in such templates.


So the starting point for many forms won't be a COMPOSITION - it is 
instead a different logical container that groups data that result 
from one or more queries, into a 'use group', i.e the group of data 
items intended to be visualised or used as a report etc.


One problem today is that people trying to define screens for visual 
applications are forced (more or less) to create templates starting 
with COMPOSITIONs, which is incorrect; my impression is that such 
templates are only used for data capture and that other display forms 
are modelled in various non-standard ways, or not at all.


I think annotations (based on paths) will be useful, but I not 
completely adequate to achieved what is needed.


- thomas


On 19/02/2018 07:49, Erik Sundvall wrote:

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 explaining in detail. So a GUI-hint-annotated template 
based on another "normal" content aggregation/constraint-focused 
template would be a way to do it. I guess the effect in a resulting 
operational template (OPT) is essentially the same no matter how many 
layers of templates you choose to work with, right? So a 
form/GUI-renderer based on OPTs does not care how you layer the 
design, but your maintenance headaches might be affected if not 
separating things at design time.


I agree with Diego and Bert and suggest starting experimenting in the 
AM end (for example using annotations with GUI-hints in templates) 
and see how far that takes us, before possibly considering extending 
the RM (or whatever *M).


Annotations do not require any changes to AM or RM, the mechanism is 
already defined in the specifications. Conventions regarding patterns 
or prefixes in annotation keys and/or annotation values will likely 
give enough to start with.


A (not so very thought through yet) possible example of annotation 
use for application building is available in picture 40 (and 
supported by picture 36 in
https://drive.google.com/file/d/1kxXeJMe0ltfLlchGA0Lm8mfOD-PQDLFy/view?usp=sharing 



//Erik

mån 19 feb. 2018 kl. 10:22 skrev Bert Verhees >:


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


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org


http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org





___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 




___
openEHR-technical 

Re: Templates for application form development

[Thomas Beale]

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 EHR.


Displaying data is a different question - it may be EHR data, it may be 
demographic data, and it may be something else entirely. So the data 
items we want to mention in templates are mostly of ENTRY level, and 
will be the results of queries; the relevant queries could be included 
in such templates.


So the starting point for many forms won't be a COMPOSITION - it is 
instead a different logical container that groups data that result from 
one or more queries, into a 'use group', i.e the group of data items 
intended to be visualised or used as a report etc.


One problem today is that people trying to define screens for visual 
applications are forced (more or less) to create templates starting with 
COMPOSITIONs, which is incorrect; my impression is that such templates 
are only used for data capture and that other display forms are modelled 
in various non-standard ways, or not at all.


I think annotations (based on paths) will be useful, but I not 
completely adequate to achieved what is needed.


- thomas


On 19/02/2018 07:49, Erik Sundvall wrote:

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 explaining in detail. So a GUI-hint-annotated template 
based on another "normal" content aggregation/constraint-focused 
template would be a way to do it. I guess the effect in a resulting 
operational template (OPT) is essentially the same no matter how many 
layers of templates you choose to work with, right? So a 
form/GUI-renderer based on OPTs does not care how you layer the 
design, but your maintenance headaches might be affected if not 
separating things at design time.


I agree with Diego and Bert and suggest starting experimenting in the 
AM end (for example using annotations with GUI-hints in templates) and 
see how far that takes us, before possibly considering extending the 
RM (or whatever *M).


Annotations do not require any changes to AM or RM, the mechanism is 
already defined in the specifications. Conventions regarding patterns 
or prefixes in annotation keys and/or annotation values will likely 
give enough to start with.


A (not so very thought through yet) possible example of annotation use 
for application building is available in picture 40 (and supported by 
picture 36 in
https://drive.google.com/file/d/1kxXeJMe0ltfLlchGA0Lm8mfOD-PQDLFy/view?usp=sharing 



//Erik

mån 19 feb. 2018 kl. 10:22 skrev Bert Verhees >:


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


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org


http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org





___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Erik Sundvall]

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 explaining in detail. So a GUI-hint-annotated template based on
another "normal" content aggregation/constraint-focused template would be a
way to do it. I guess the effect in a resulting operational template (OPT)
is essentially the same no matter how many layers of templates you choose
to work with, right? So a form/GUI-renderer based on OPTs does not care how
you layer the design, but your maintenance headaches might be affected if
not separating things at design time.

I agree with Diego and Bert and suggest starting experimenting in the AM
end (for example using annotations with GUI-hints in templates) and see how
far that takes us, before possibly considering extending the RM (or
whatever *M).

Annotations do not require any changes to AM or RM, the mechanism is
already defined in the specifications. Conventions regarding patterns or
prefixes in annotation keys and/or annotation values will likely give
enough to start with.

A (not so very thought through yet) possible example of annotation use for
application building is available in picture 40 (and supported by picture
36 in
https://drive.google.com/file/d/1kxXeJMe0ltfLlchGA0Lm8mfOD-PQDLFy/view?usp=sharing


//Erik

mån 19 feb. 2018 kl. 10:22 skrev Bert Verhees :

> 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
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Bert Verhees]

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 sloppy English in my previous message, this time changing the 
meaning, I changed the quote below, I am awake now, will not happen 
again, excuse me)




2018-02-19 10:15 GMT+01:00 Bert Verhees >:


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*d* per purpose, and mixing
purposes in a single template does *no**t* seem good idea to me



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Diego Boscá]

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 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
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Bert Verhees]

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



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Erik Sundvall]

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 openEHR mailing lists.

//Erik

(We should link to some old list posts on the topic in that wiki page Tom
created)






>
> 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 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 since some parts are
> closer to openEHR data/query definitions and some will be closer to
> GUI-implementation/visualisation/layout frameworks (like Angular etc) that
> should likely not be reinvented by openEHR but that (sometimes at an
> annoying speed) keep changing versions and popularity faster than the
> RM/AM/AQL related data definition framework should...
>
> 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/ are two starting candidates
> for experimentation? (Both have partially declarative design, but other
> suggestions are of course welcome) Then mechanisms in those platforms could
> be reused rather than reinvented.
>
> Also looking at the things done in the format used/shared by Marand and
> DIPS is an interesting input for gathering requirements.
>
> //Erik Sundvall
>
> sön 18 feb. 2018 kl. 11:51 skrev Thomas Beale :
>
>>
>>
>> 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 share
>> > it :)
>> >
>>
>> I think any existing UI/template specification / app modelling would be
>> useful to share - possibly on the wiki - let me know if you need a page
>> there.
>>
>> My aim would be to get closer to an IDE application building tool for
>> clinical people to at least build a POC application that works,
>> something like Balsamiq but with real data connections built in.
>> Marand's EhrExplorer does some of this, and it would also be useful to
>> extract some of the semantics of that tool into a standard specification
>> to support this kind of thing.
>>
>> - thomas
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
> --
> Sent from mobile.
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- 
Sent from mobile.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Thomas Beale]

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 suggest to make a sub-page, and then put a link and short 
summary description at the bottom of the page I have created.


- thomas
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[GF]

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 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 since some parts are 
> closer to openEHR data/query definitions and some will be closer to 
> GUI-implementation/visualisation/layout frameworks (like Angular etc) that 
> should likely not be reinvented by openEHR but that (sometimes at an annoying 
> speed) keep changing versions and popularity faster than the RM/AM/AQL 
> related data definition framework should...
> 
> 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/  are two 
> starting candidates for experimentation? (Both have partially declarative 
> design, but other suggestions are of course welcome) Then mechanisms in those 
> platforms could be reused rather than reinvented.
> 
> Also looking at the things done in the format used/shared by Marand and DIPS 
> is an interesting input for gathering requirements.
> 
> //Erik Sundvall
> 
> sön 18 feb. 2018 kl. 11:51 skrev Thomas Beale  >:
> 
> 
> 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 share
> > it :)
> >
> 
> I think any existing UI/template specification / app modelling would be
> useful to share - possibly on the wiki - let me know if you need a page
> there.
> 
> My aim would be to get closer to an IDE application building tool for
> clinical people to at least build a POC application that works,
> something like Balsamiq but with real data connections built in.
> Marand's EhrExplorer does some of this, and it would also be useful to
> extract some of the semantics of that tool into a standard specification
> to support this kind of thing.
> 
> - thomas
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> 
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> 
> -- 
> Sent from mobile.
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Diego Boscá]

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 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 translation work :)
>>
>> On Feb 18, 2018 7:51 AM, "Thomas Beale"  wrote:
>>
>>
>>
>> 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 share it :)
>>>
>>>
>> I think any existing UI/template specification / app modelling would be
>> useful to share - possibly on the wiki - let me know if you need a page
>> there.
>>
>> My aim would be to get closer to an IDE application building tool for
>> clinical people to at least build a POC application that works, something
>> like Balsamiq but with real data connections built in. Marand's EhrExplorer
>> does some of this, and it would also be useful to extract some of the
>> semantics of that tool into a standard specification to support this kind
>> of thing.
>>
>> - thomas
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Diego Boscá]

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
> this a while ago on the lists but catched not much attention.
>
> Need to do a little translation work :)
>
> On Feb 18, 2018 7:51 AM, "Thomas Beale"  wrote:
>
>
>
> 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 share it :)
>>
>>
> I think any existing UI/template specification / app modelling would be
> useful to share - possibly on the wiki - let me know if you need a page
> there.
>
> My aim would be to get closer to an IDE application building tool for
> clinical people to at least build a POC application that works, something
> like Balsamiq but with real data connections built in. Marand's EhrExplorer
> does some of this, and it would also be useful to extract some of the
> semantics of that tool into a standard specification to support this kind
> of thing.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Pablo Pazos]

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 translation work :)

On Feb 18, 2018 7:51 AM, "Thomas Beale"  wrote:



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 share it :)
>
>
I think any existing UI/template specification / app modelling would be
useful to share - possibly on the wiki - let me know if you need a page
there.

My aim would be to get closer to an IDE application building tool for
clinical people to at least build a POC application that works, something
like Balsamiq but with real data connections built in. Marand's EhrExplorer
does some of this, and it would also be useful to extract some of the
semantics of that tool into a standard specification to support this kind
of thing.

- thomas



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_
lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Tony Shannon]

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
between UI & CDR
PulseTile- frontend UX/UI framework for healthcare


A few comments;
Point 1
We know that structured data in an EHR is essential for lots of reasons,
inc querying, CDS, workflow etc etc. We also know that most folk who craft
their application UI based on their data models end up with an UX
application that is horrible & tedious to use at the frontend. (My
emergency physician background was witness to that in many many
applications.
I also recall leading work by Helma Van Der Linden about the challenges in
automatically mapping from openEHR to the UI in a decent to use fashion..
non trivial was my recollection of our discussion.

So our approach has been a very deliberately clinically driven, user
centred design approach, which has then driven the openEHR templates that
underpin, but the UX is #1 in importance to frontline clinicians, not the
data models.
(Still , all the key data is our stack created/updated/persisted in
EtherCIS (& Marand) CDR using a RESTful JSON API. )


Point 2
We know that many folk are doing/ do direct mapping from data models to UI
eg we could have chosen to feed the UI framework with openEHR JSON API
directly
We also know that then raises somewhat of a data migration challenge if
you're sitting on any legacy non openEHR data (which most folk are), hence
we use a middleware element (QEWDjs) which handles the mapping from both
openEHR & non openEHR sources into the same UI JSON.
We explain the rationale for that in this article, where we describe 5 step
wise levels of integration between non openEHR & openEHR systems, that our
UX framework accomodates
http://ripple.foundation/2016/02/integrated-care-digital-records-maturity-model/
This key openEHR Jumper technology in QEWD handles the mapping between
openEHR/ non openEHR (eg FHIR) and UI side JSON with a simple JSON2JSON
mapping tool. as per this video.
https://www.youtube.com/watch?v=iaGGGgJdWvM=3=PLNxHSK29ViKLrrhdPTqbYr6XGTya4uGBv

(Some of you feel this middleware layer is an unnecessary element in an
openEHR environment & I can understand that perspective. All I can tell you
is that such a layer is essential in any environment we're working in where
folk have existing data & exploring a move towards openEHR)


Point 3
So the UX framework has then been designed to be pretty simple and generic
and reusable for lots of uses.
In particular it aims to support "business/clinical analytics", "multi
patient cohort views" and "single patient that I need to look after who is
right in front of me views" , as in my experience these are the key
processes we need to support.
This framework is documented here http://docs.pulsetile.com/
and a video cast here gives an overview here
https://www.youtube.com/watch?v=jpfIZ_HWr3w=2=PLNxHSK29ViKLrrhdPTqbYr6XGTya4uGBv

and for better/worse we have supported in both Angular & React frameworks
for now, with a core set of widgets "Tiles" and a plugin approach to extra
Tiles.
see here https://github.com/PulseTile
I wont get into the large & evolving range of choice in frontend
frameworks, but if you are trying to keep track of them take a look here
https://github.com/gothinkster/realworld
We've heard mention of microservices in a recent thread, not to mention the
possibility of https://micro-frontends.org/


Lastly a final UI side JSfiddle, to explain direction of travel here
https://jsfiddle.net/tshannon/hgypL94d/

Imagine an open source stack..
#openEHR CDR pre populated with top 10/20/50 templates for common use +
#middleware with related openEHR_2_UI mapping (or other eg FHIR API) via
JSON2JSON mappings (some will argue unnecessary, I refer back to point 2)
#UI framework with top 10/20/50 UI widgets ("Tiles") with the ability to
add your own template. JSON2JSON mapping & UI widget)
.. thats probably the best way to summarise where we are heading with this
in 2018


Perhaps to finish, even if your working from openEHR 2 UI directly, please
remember the busy clinician at the frontline who has to contend & work with
the UI (not the data model).. lets aim to get tools out there that ease
their load..

Hope that's of interest/ helps

Tony



Dr. Tony Shannon
Director, Ripple Foundation   ripple.foundation
tony.shannon@ripple.foundation
+44.789.988.5068 (UK)
+353.89.457.6011 (Ireland)











On 18 February 2018 at 15: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
> https://angular.io/ and https://reactjs.org/ are two starting candidates
> 

Re: Templates for application form development

[Bert Verhees]

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

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Bert Verhees]

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 
https://angular.io/ and https://reactjs.org/ are two starting 
candidates for experimentation? (Both have partially declarative 
design, but other suggestions are of course welcome) Then mechanisms 
in those platforms could be reused rather than reinvented.


I think I must have been run out of credit, since my emails yesterday. 
But still I take my chance.


I must warn, Angular is a very complex environment, with much more 
functionality then just showing GUI's. I am afraid you load a lot of 
complexity which will not pay out. By the way, I thought that Marand 
still uses AngularJS, I don't know how I got this information, but check 
it before deciding for it. AngularJS which is the previous version, and 
is in fact not further developed and not maintained.
This for generating Angular code or ReactJS code (which is even more 
complex because it is a whole different paradigm)


There are many disadvantages of using a complex framework.
The disadvantage of using Angular or React is that it is not something 
that works with easy generated code, except when you want to impose the 
use of Angular to the OpenEhr developers, which will become 
contradictory with the word "Open". I think it is best to offer the 
developer as much freedom as necessary, it makes the effort to create 
this also longer usable and ask for less maintenance.


Therefor I wouldn't go the way of an existing framework anyway, it is 
much easier to generate javascript (as simple as possible) and GUI 
identifiers together with the necessary REST-calls
The generated javascript can be quite simple, a  GUI-control, an 
identifier to read the content, and a REST-call which uses the content 
to do its thing.
When developers want, they an copy and paste the generated javascript 
into their web-framework in order to maintain the own graphical layout 
and application functionality around the generated code.

Integration will become much easier.

You could optionally make it more complex (as a second step goal) and 
still work for the simple copy/past situation. This complexity could be 
in validating datasets in the browser by Javascript/Typescript, so there 
will be only network activity when the dataset is validated and OK. That 
would really do the user-experience good, especially on mobile devices.


But this second step could be a later target, first having the simple 
javascripts generated and the REST calls generated would be a good 
target to start with.


Best regards
Bert





yes - this is the sort of thing I have in mind. The tool would 
function as follows:


  * represent UI forms and ?other UI behaviours (some screen workflow)
as archetypes+templates of classes that generically represent such
things
  * use one or a set of templates to represent an application
  * generate the OPTs of these templates, as ADL2 or JSON, YAML,
whatever is convenient
  * perform OPT => GUI transform, injecting some UI styling profile
info, to get directly consumable artefacts for the UI framework.

experts on the UI side will be able to help refine the details of this.

THe 'smart split' of data / UI semantics will be the key to making 
this workable.


- thomas




Also looking at the things done in the format used/shared by Marand 
and DIPS is an interesting input for gathering requirements.


//Erik Sundvall



--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Thomas Beale]

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/ are two starting 
candidates for experimentation? (Both have partially declarative 
design, but other suggestions are of course welcome) Then mechanisms 
in those platforms could be reused rather than reinvented.


yes - this is the sort of thing I have in mind. The tool would function 
as follows:


 * represent UI forms and ?other UI behaviours (some screen workflow)
   as archetypes+templates of classes that generically represent such
   things
 * use one or a set of templates to represent an application
 * generate the OPTs of these templates, as ADL2 or JSON, YAML,
   whatever is convenient
 * perform OPT => GUI transform, injecting some UI styling profile
   info, to get directly consumable artefacts for the UI framework.

experts on the UI side will be able to help refine the details of this.

THe 'smart split' of data / UI semantics will be the key to making this 
workable.


- thomas




Also looking at the things done in the format used/shared by Marand 
and DIPS is an interesting input for gathering requirements.


//Erik Sundvall



--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Erik Sundvall]

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 since some parts are
closer to openEHR data/query definitions and some will be closer to
GUI-implementation/visualisation/layout frameworks (like Angular etc) that
should likely not be reinvented by openEHR but that (sometimes at an
annoying speed) keep changing versions and popularity faster than the
RM/AM/AQL related data definition framework should...

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/ are two starting candidates
for experimentation? (Both have partially declarative design, but other
suggestions are of course welcome) Then mechanisms in those platforms could
be reused rather than reinvented.

Also looking at the things done in the format used/shared by Marand and
DIPS is an interesting input for gathering requirements.

//Erik Sundvall

sön 18 feb. 2018 kl. 11:51 skrev Thomas Beale :

>
>
> 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 share
> > it :)
> >
>
> I think any existing UI/template specification / app modelling would be
> useful to share - possibly on the wiki - let me know if you need a page
> there.
>
> My aim would be to get closer to an IDE application building tool for
> clinical people to at least build a POC application that works,
> something like Balsamiq but with real data connections built in.
> Marand's EhrExplorer does some of this, and it would also be useful to
> extract some of the semantics of that tool into a standard specification
> to support this kind of thing.
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
-- 
Sent from mobile.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Thomas Beale]

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 share 
it :)




I think any existing UI/template specification / app modelling would be 
useful to share - possibly on the wiki - let me know if you need a page 
there.


My aim would be to get closer to an IDE application building tool for 
clinical people to at least build a POC application that works, 
something like Balsamiq but with real data connections built in. 
Marand's EhrExplorer does some of this, and it would also be useful to 
extract some of the semantics of that tool into a standard specification 
to support this kind of thing.


- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[A Verhees]

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 the first
announcement of a good plan.

Best regards
Bert

Op za 17 feb. 2018 22:53 schreef A Verhees :

> 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 has dependencies to rm data types, only
> because of codephrase. Wouldn't it be possible to avoid that? This also
> creates a circular dependency at construction of several RM classes. They
> need the OpenEhr terminology when constructed, and the terminology needs
> the RM codephrase.
>
> The archetype_Id is inherited from object_id, but why is that necessary?
> What is the advantage?
>
> Of course it is not only design, it is also the developers, they create
> those large libraries, but they are inspired by the theoretical
> architecture-plan, and maybe they need to do that to avoid circular library
> references.
>
> There is, in my opinion a need to split the RM. Rongs did that a few years
> ago, he had an Ehr-RM and a  (was it...) common RM. A step in a good
> direction.
>
> 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.
>
> Bert
>
> Op 17 feb. 2018 22:12 schreef "Thomas Beale" :
>
>
>
> 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 Resource specification, in the
> BASE component
> ,
> allowing them to be re-used where needed. (They were in the AOM but are
> needed outside of there).
>
>  - thomas
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Pablo Pazos]

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 idea forward.

Please let me know how I can help.

On Feb 17, 2018 4:07 PM, "Thomas Beale"  wrote:

I've been recently messing around with ADL-designer, and thinking more
about how to do application building with templates. A few things are
becoming clearer to me. Firstly, templates based on COMPOSITION (or PARTY,
PERSON etc, for demographics) are potentially good for data capture, but
don't in general make sense for data retrieval.

For a retrieval data set, e.g. a screen containing a combination of
demographics, EHR clinical, other info, we need another kind of container.
Let's call this DATA_SET for the moment, and assume it is defined as
follows:

class DATA_SET inherit LOCATABLE
content: LOCATABLE [*]
end

Then an archetype of this could be built for a screen, and it could insert
SECTIONS purely for display purposes. Maybe it could include style
information. So let's imagine that instead of just SECTIONs we could use
something a bit smarter, like DATA_GROUP. We could then create a template
like the following (each included archetype is actually an overlay based on
an underlying archetype):

DATA_SET[id1] matches {
content matches {
DATA_GROUP[id2] matches {
   name matches {[at20]} -- "Patient details"
   style matches {1} -- area; from an enumeration of
tabs|menu|area|etc
   items matches {
use_archetype PERSON[id3, openEHR-EHR-PERSON.ovl_
patient_details_1.v1]
   }
}
DATA_GROUP[id4] matches {
   name matches {[at21]} -- "Clinical"
   style matches {1} -- area; from an enumeration of
tabs|menu|area|etc
   items matches {
DATA_GROUP[id6] matches {
   name matches {[at22]} -- "First trimester"
   style matches {0} -- tabs
   items matches {
use_archetype OBSERVATION [id7,
openEHR-EHR-OBERVATION.ovl_first_trimester_summary_1.v1]
   }
}
DATA_GROUP[id8] matches {
   name matches {[at23]} -- "Second trimester"
   style matches {0} -- tabs
   items matches {
use_archetype OBSERVATION [id9,
openEHR-EHR-OBERVATION.ovl_second_trimester_summary_1.v1]
   }
}
DATA_GROUP[id10] matches {
   name matches {[at24]} -- "Third trimester, first part"
   style matches {0} -- tabs
   items matches {
use_archetype OBSERVATION [id11,
openEHR-EHR-OBERVATION.ovl_third_trimester_summary_1.v1] -- overlay 1
   }
}
DATA_GROUP[id12] matches {
   name matches {[at25]} -- "Third trimester, last month"
   style matches {0} -- tabs
   items matches {
use_archetype OBSERVATION [id13,
openEHR-EHR-OBERVATION.ovl_first_trimester_summary_2.v1] -- overlay 2
   }
}
}
}
}
}

Notice that now we have demographic data (magenta) and EHR data (blue)
easily mixed in; we have a rough screen layout defined, something like two
HBOX areas, with the second one having tabs inside for the various
pregnancy trimesters.

In this construction, the only real data are the included archetypes; the
outer DATA_SET and DATA_GROUPs are just defined structures that are created
on the fly by a screen renderer. Different types of DATA_GROUP could be
used to provide the UI hints we often talk about - use tabs, use a box with
a name, and so on - people familiar with the typical UI elements like HBOX,
VBOX, TREE, MENU, MENU_ITEM, DATE_FIELD, TEXT_FIELD (the names differ
across UI toolkits) will see that this approach could be used to more or
less fully define whole screens. A similar thing could be done to define
messages or documents.

Paths through such a structure would effectively be paths to parts of a
form (or a message), and could be referenced in other sections of the
template to control visualisation.

We could embed the generating queries as well for example:

DATA_SET[id1] matches {
content matches {
DATA_GROUP[id2] matches {
   name matches {[at20]} -- first trimester
   query matches {
*   "SELECT obs*
*FROM *
*EHR[$ehr_id] CONTAINS *
*summary**
COMPOSITION[openEHR-EHR-COMPOSITION.pregnancy_summary.v1]*
*WHERE*
*summary/context/start_dat**e **> **$current_date - P1Y*
*"*
   }
   style 

Re: Templates for application form development

[A Verhees]

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 has dependencies to rm data types, only
because of codephrase. Wouldn't it be possible to avoid that? This also
creates a circular dependency at construction of several RM classes. They
need the OpenEhr terminology when constructed, and the terminology needs
the RM codephrase.

The archetype_Id is inherited from object_id, but why is that necessary?
What is the advantage?

Of course it is not only design, it is also the developers, they create
those large libraries, but they are inspired by the theoretical
architecture-plan, and maybe they need to do that to avoid circular library
references.

There is, in my opinion a need to split the RM. Rongs did that a few years
ago, he had an Ehr-RM and a  (was it...) common RM. A step in a good
direction.

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.

Bert

Op 17 feb. 2018 22:12 schreef "Thomas Beale" :



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 Resource specification, in the
BASE component
,
allowing them to be re-used where needed. (They were in the AOM but are
needed outside of there).

 - thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_
lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Thomas Beale]

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 Resource specification, in the 
BASE component 
, 
allowing them to be re-used where needed. (They were in the AOM but are 
needed outside of there).


 - thomas
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[A Verhees]

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 should leave the idea of OpenEhr being a single system. It is an
anti-pattern in the microservices paradigm.

Too many dependencies, too much code replication, the monolithic kernel
paradigm should be left.

So I  favour an AOM with no shared dependencies with the EHR RM. The same
idea for the Form classes. Have an own class system with no dependencies
outside the system.

But the idea of a Form RM / template I think is very good, and can be a
great help for software designers when tooling supports it.

I will study the specs tomorrow, this was what came to mind when I saw your
post

Best regards
Bert

Op 17 feb. 2018 20:07 schreef "Thomas Beale" :

> I've been recently messing around with ADL-designer, and thinking more
> about how to do application building with templates. A few things are
> becoming clearer to me. Firstly, templates based on COMPOSITION (or PARTY,
> PERSON etc, for demographics) are potentially good for data capture, but
> don't in general make sense for data retrieval.
>
> For a retrieval data set, e.g. a screen containing a combination of
> demographics, EHR clinical, other info, we need another kind of container.
> Let's call this DATA_SET for the moment, and assume it is defined as
> follows:
>
> class DATA_SET inherit LOCATABLE
> content: LOCATABLE [*]
> end
>
> Then an archetype of this could be built for a screen, and it could insert
> SECTIONS purely for display purposes. Maybe it could include style
> information. So let's imagine that instead of just SECTIONs we could use
> something a bit smarter, like DATA_GROUP. We could then create a template
> like the following (each included archetype is actually an overlay based on
> an underlying archetype):
>
> DATA_SET[id1] matches {
> content matches {
> DATA_GROUP[id2] matches {
>name matches {[at20]} -- "Patient details"
>style matches {1} -- area; from an enumeration of
> tabs|menu|area|etc
>items matches {
> use_archetype PERSON[id3, openEHR-EHR-PERSON.ovl_
> patient_details_1.v1]
>}
> }
> DATA_GROUP[id4] matches {
>name matches {[at21]} -- "Clinical"
>style matches {1} -- area; from an enumeration of
> tabs|menu|area|etc
>items matches {
> DATA_GROUP[id6] matches {
>name matches {[at22]} -- "First trimester"
>style matches {0} -- tabs
>items matches {
> use_archetype OBSERVATION [id7,
> openEHR-EHR-OBERVATION.ovl_first_trimester_summary_1.v1]
>}
> }
> DATA_GROUP[id8] matches {
>name matches {[at23]} -- "Second trimester"
>style matches {0} -- tabs
>items matches {
> use_archetype OBSERVATION [id9,
> openEHR-EHR-OBERVATION.ovl_second_trimester_summary_1.v1]
>}
> }
> DATA_GROUP[id10] matches {
>name matches {[at24]} -- "Third trimester, first part"
>style matches {0} -- tabs
>items matches {
> use_archetype OBSERVATION [id11,
> openEHR-EHR-OBERVATION.ovl_third_trimester_summary_1.v1] -- overlay 1
>}
> }
> DATA_GROUP[id12] matches {
>name matches {[at25]} -- "Third trimester, last month"
>style matches {0} -- tabs
>items matches {
> use_archetype OBSERVATION [id13,
> openEHR-EHR-OBERVATION.ovl_first_trimester_summary_2.v1] -- overlay 2
>}
> }
> }
> }
> }
> }
>
> Notice that now we have demographic data (magenta) and EHR data (blue)
> easily mixed in; we have a rough screen layout defined, something like two
> HBOX areas, with the second one having tabs inside for the various
> pregnancy trimesters.
>
> In this construction, the only real data are the included archetypes; the
> outer DATA_SET and DATA_GROUPs are just defined structures that are created
> on the fly by a screen renderer. Different types of DATA_GROUP could be
> used to provide the UI hints we often talk about - use tabs, use a box with
> a name, and so on - people familiar with the typical UI elements like HBOX,
> VBOX, TREE, MENU, MENU_ITEM, DATE_FIELD, TEXT_FIELD (the names differ
> across UI toolkits) will see that this approach could be used to more or
> less fully define whole screens. A similar thing could be done to define
> messages or documents.
>
>