On 10/11/2010 16:16, Erik Sundvall wrote: > Tom, did I really express myself in such an unclear way or did you not > read properly? Or did you respond to the wrong thread somehow? Perhaps > i misinterpret your tone and arguments so please clarify if you have > problems with the following:
Apologies - I responded after reading the first version of your post, which had no point 2, but I was also trying to respond to more general criticisms (other people have said get rid of tables etc), not specifically just your post. ;-) (It took me a while to write that post, and I did not see your final version in time - seems we are in fierce agreement ;-) your point about the class names is of course a good one. We chose names that came from the ontological analysis, which some people will disagree with (or agree with, but hate our choice of names!). But in the end, the meaning (and therefore arguably the best name) of a class comes from its intentional definition, and nothing else. So your painful class name proves exactly this point. I would of course argue for a /shorter/ name, but going on your approach, Observation could be named in 13606 as something like 'DataHistory' or so. Personally, I would rather stick with 'Observation', because intuitively most people get the fact that it is about data in the past, and they generally immediately understand why it has a time-series structure. But I accept that this is only one way of seeing this, and would not be religious about it. 'Evaluation' as it turns out is an even more contentious name; we originally proposed 'Assessment', 'Opinion' and other similar names. Sticking with your theory, it possibly should be called 'AnythingYouLike', 'GenericEntry' or somesuch, but the problem going down this road is that it then obscures the link between the ontological model (I mean the problem-solving model of doing healthcare, that gives rise to categories like Observation, Evaluation, Instruction, Action, and all other similar models, like G-EPJ, the Swedish process model and so on) and the information model, and it makes it harder (in my view) for newcomers to know which Entry class to use for what. For those unaware, we started the openEHR/13606 mapping here <http://www.openehr.org/wiki/display/stds/openEHR+to+ISO+13606-1%2C+ISO+21090+mapping>, and you can see if you look carefully that there is an initial description of where a purely automated conversion algorithm that Erik is talking about goes. - t > > 1. tables, clusters etc > > I did not suggest that we should avoid having a single fixed way of > defining table structures in openEHR. I suggested using a new > attribute to indicate if a cluster is conceptually/graphically to > interpreted as a table, list etc. instead of using separate classes > for this purpose. Of course we need strict definitions of allowed > values for this attribute (an enumeration or a list in the openEHR > terminology, just as in other parts of openEHR presently). Of course > specifications should include exactly how to interpret the clusters as > rows and columns. > > Ian and Sam indicate that this would also have the benefit of allowing > tables anywhere in a cluster hierarchy instead of only at top level. > Do you have any objection against this provided that it is introduced > in a well defined manner as described in the previous paragraph? > > Your argumentation sounds like somebody suggested that tables are not > needed in openEHR at all or that they should be defined in random > different ways. > > 2. Observations etc. > > I suggested that ISO 13606 gets extended with the openEHR ENTRY > subclasses. Here I did not suggest changes to openEHR. (Even though I > tried to say the class names can be confusing if you for some reason > strongly believe that a technical class name only can be used for > exactly what your own perception of that English word means.) Perhaps > your OBSERVATION examples are just your way of expressing that you > support my idea and why it is important to have the ENTRY subclasses > to encourage consistency. > > The part about automatically converting openEHR ENTRY subclass > structures to 13606, was definitely not a suggestion to remove them > from openEHR. Instead it was more of an enquiry if it was at all > possible in a non-destructive way. If it is, then openEHR archetype > modeling, queries etc could after auto-conversion be used somewhat > safely in a setting where you only have 13606 available. > > Best regards, > Erik Sundvall > erik.sundvall at liu.se <mailto:erik.sundvall at liu.se> > http://www.imt.liu.se/~erisu/ <http://www.imt.liu.se/%7Eerisu/> Tel: > +46-13-286733 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> Chartered IT Professional Fellow, BCS, British Computer Society <http://www.bcs.org.uk/> Health IT blog <http://www.wolandscat.net/> * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101110/9162597e/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101110/9162597e/attachment.jpg>
