More people than you think still read and write ADL by hand, as
openEHR clinical model is not the only language you can build
archetypes (for instance, you can do archetypes of openEHR
demographics, CEN EN13606 clinical model or demographics). However,
it's true that available tools support or plan to support different
models, but the tools that support those models are still unknown to a
lot of potential users

2009/7/23 Greg Caulton <caultonpos at gmail.com>:
>
>>
>> Date: Wed, 22 Jul 2009 15:16:20 +0200
>> From: hepabolu <hepabolu at gmail.com>
>> Subject: Re: Issues around UI technologies and bindings to back end
>> To: For openEHR technical discussions <openehr-technical at openehr.org>
>> Message-ID: <4A671124.7020002 at gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Seref Arikan said the following on 22/7/09 11:39:
>> > Now about UI - model relationship, my view is the GUI layer is way too
>> > complex and diverse to include in openEHR specifications, even a subset
>> > of the UI related stuff would be enough to introduce more problems than
>> > it solves.
>> > IF there emerges a cross platform AND cross technology declerative
>> > markup for GUI and GUI interactions and bindings, and this is a big if,
>> > then it may be considered, otherwise, my personal opinion is to simply
>
>
> I agree, to start integrating UI related content into the archetypes is a
> very bad idea.
>
> Most modern UIs follow a Model-View-Controller approach.? For PatientOS
> Archetypes provide the data elements.? The relationships and constraints
> within the archetype data elements is implemented in our model.? We have
> different views - fat client, web client which are implemented through
> controllers written in java or javascript.
>
> Atttempts to push everything into the archetype definition would create a
> complex beast which would defeat KISS principal.
>
> As a side note I also think the ADL files is hampering adoption - not for us
> as there is a Java parser.? Since everything that is the ADL must be
> expressable in XML (otherwise interoperability of the definitions would be
> problematic) - why have both - XML is ubiquitous and I think the benefits of
> readibility of an ADL file is no longer needed since there are tools which
> replace it - how many people read an ADL file any more?
>
> --
> Gregory Caulton
> Principal at PatientOS Inc.
> personal email: caultonpos at gmail.com
> http://www.patientos.com
> corporate: (888)-NBR-1EMR || fax ?857.241.3022
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>



-- 
Diego Bosc? Tom?s <diebosto at fis.upv.es>
                              <yampeku at gmail.com>
Grupo IBIME
Instituto ITACA - Universidad Polit?cnica de Valencia
Acceso B
Edificio 8G
Camino Vera s/n
46022 VALENCIA (Spain)
tel: +34 963 875 277

http://ibime.upv.es
http://www.linkehr.com


Reply via email to