Hi Koray, I agree with Thomas here, Koray, but I take your point about the separation into a further layer represents added potential development complexity. I think we should expect tools to handle this in the same way that a complex development environment like Visual Studio handles various layers of application 'code' and resources within a seamless environment. You should not have to think about these separate layers during development.
Your comments about 'isCoreConcept' are very interesting because I think you have touched upon an issue in semantics that we are coming across, particularly when modelling detailed clinical findings. I had been thinking about the same issue from a different angle, essentially how to cleanly model findings where the requirement might expand gradually from a Y/N response to a full blown complex structure, in different clinical contexts and over time as more detailed requirements emerge. It touches upon the crucial areas of integration with SNOMED post-coordinations and the handling of Questionnaire type structures but I think we should continue this discussion is a separate clinical thread because it is definitely not just an issue of GUI. Ian Dr Ian McNicoll office / fax? +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst,?Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 8 December 2010 14:14, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > On 06/12/2010 21:06, Koray Atalag wrote: > > For us this was a no brainer because I think ALL pure GUI stuff should go to > Templates. I have explained my reasoning in a previous message but shortly > archetypes and templates are all about information capture and validation > (i.e. which data items, their organisation, and basic constraints for > validation). Real world semantics are delegated to terminology (i.e. heart > murmur IS-A symptom of heart disease or cardia is PART-OF stomach etc). I > think we need to keep archetypes fairly pure and generic with large scale > interoperability in mind. However templates provide all the convenience > needed otherwise. > > I strongly believe we do_not_need another layer of modelling for GUI because > referring back to my definition of clinical models, these are to do with > information capture and validation... > > Only one problem with this reasoning: templates are often used for things > other than the GUI, e.g. messages. In the future, they will end up being > used for reports as well. In general, I believe the openEHR template will be > an artefact defining a specific data set (including optionality where > needed), and auxiliary artefacts will always be needed to connect that > definition to its target technology: a specific kind of GUI form, message > infrastructure or relational mapping or querying environment > > - thomas > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
