It seems this message didn't reached the list, forwarding :) From: [email protected] To: gfrer at luna.nl; thomas.beale at oceaninformatics.com Subject: RE: CIMI archetype examples using latest openEHR AOM & ADL Date: Sun, 16 Feb 2014 12:34:26 -0300
Hi Gerard, If there are presentation requirements, I would suggest to create UI Templates (as we call them) and put there the panel constructs/semantics **. That would be another semantic layer: RM <- AM <- OTP <- UIT If there is some related data and there is the need to associate an interpretation, I would think of LINKed COMPOSITIONs, thinking about and information system: - in time 0, a data set is created, e.g. a study result (maybe many studies/results in the same dataset)- that should be committed to the EHR- in time 1, data is pulled from the EHR- an interpretation is created, another data set is created- that should be committed to the EHR, at this time we can link the first COMPOSITION with this second COMPOSITION I would prefer to do this at a COMPOSITION level because it is the committal unit. Thinking of a system that links entries, the user should select some specific entries to make an interpretation (if there are more entries than the ones that should be interpreted), but the interpretation itself should be in another COMPOSITION. What you say about the external resource holding the PANEL definition, I would prefer to create a new COMPOSITION with selected entries from other COMPOSITIONs, and the PANEL would be just a TEMPLATE defining the COMPOSITION and reusing the same ARCHETYPES, and maybe another one to model the interpretation of the data. Taking and step back, I guess CIMI what's to solve with structure something that can be solved defining a process, workflow or methodology that defines how to do things from the modeling perspective, instead of where to record things or how to display info on a screen. Sorry if I misunderstood something, I think I don't have the full picture :) ** Just for context, I've been working with presentation of archetyped data for a while, we have designed very simple UI Templates for the EHRGen project, and in 2013 we leaded a project on the Engineering University here in Montevideo to improve the UI Template model and an UI generation tool for different technologies (we have prototypes for Web with HTML5 and XHTML, and .Net with XAML).Now we're writing the paper, but I can show you the raw model. And maybe in a couple of months I can present that to the community to be improved and adopted as another layer in the semantic stack of the dual model, as I said, just for presentation purposes (input and display of openEHR data, and why not 13606 also!). -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com From: [email protected] Subject: Re: CIMI archetype examples using latest openEHR AOM & ADL Date: Sat, 15 Feb 2014 10:35:54 +0100 To: pazospablo at hotmail.com; thomas.beale at oceaninformatics.com Dear Pablo, As member of the En13606 Association I have access to CIMI meetings from the start. The Entry in Entry (Panel) discussion is an interesting one.I agree fully that Panels are ad-hc constructs using Statements (ENTRIES) as components.On one hand they serve the purpose of collecting items for practical purposes, convenience, short hands, etc.On the other (for some) they serve the purpose that HcP?s want to attach interpretations to a collection of Statements.And then there are practical friends from the USA that want to collect attributes from the component statements in the Panel and prevent duplication of attributes. In summary I see as drivers for this discussion: ad-hoc (Presentation) needs, adding interpreattions to a collection of statements and operational implemantational aspects (saving database space and retrieval times) In my opinion there are at least three possible solutions for the Panel to be modeled using the present structures that the RM allows without any need of changing that RM.The three options are:- Use the Composition/Section mechanism to create ad-hoc collections of ENTRIES.- Use an ENTRY that defines the Panel and its attributes and refer to constituent ENTRIES using the Semantic LINK function of the RM- Use an external resource to hold the definition of the Panel and refer to constituent ENTRIES using the Semantic LINK function of the RM I do not agree with the CIMI proposal to add COMPOUND and INDIVISIBLE Entries to the RM, in order to follow a modeling pattern as used in Intermountain.The present 13606 RM is expressive enough. Gerard Freriks+31 620347088gfrer at luna.nl On 14 feb. 2014, at 23:48, pablo pazos <pazospablo at hotmail.com> wrote:Hi Thomas,Overviewing the content on the wiki, IMO panels are an specification of sections.Is very weird from the modeling point of view to have a composite pattern (ENTRY, COMPOUND_ENTRY, ...) inside a composite pattern (CONTENT_ITEM, SECTION, ENTRY), is like defining a tree inside a tree in the model, but the initial model can also model the second, is just redundant. And IMO it doesn't add semantics to the model.It is also stated that "a panel is not a Section; it has specified and fixed [potential] content", so it could be a templated section maybe (?). Without that statement, is clear that a collection of observations is just a SECTION with slots to OBSERVATIONS (archetyped or templated).Also, the name "panel" makes me think of an user interface element, not a data structure. It would be nice to know why they need this new composite structure there, and if the requirement comes from structural needs or from information display needs.As I see it, CIMI is mixing SECTIONS and ITEM_STRUCTURES.OT, I tried to get closer to CIMI, but it seems difficult to participate from outside the EURO zone :(-- Kind regards,Eng. Pablo Pazos Guti?rrezhttp://cabolabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140219/3af45050/attachment.html>
