New UML resources for 1.0.2 release
Don't get too excited about the XMI just yet - I have done some more work on the models, including adding demographics and EHR Extract parts, and will replace the XMI soon. - thomas On 26/03/2012 10:18, Rong Chen wrote: Thanks, very useful resources indeed! /Rong On 21 March 2012 10:49, Thomas Bealethomas.beale at oceaninformatics.com wrote: On 21/03/2012 09:41, Thomas Beale wrote: I have put up some more up-to-date UML resources for the current (1.0.2) release of openEHR on this wiki page. For the moment I have done two diagrams (RM and Data types) which should help people a) understand openEHR at a glance and b) understand what classes matter for archetyping. Two generated XMI files are available - UML 2.1 (for Eclipse) and UML 2.3 (for RSA and other tools); as far as I can ascertain, they don't contain diagrams, but do faithfully represent the model semantics. If people want to actually share diagrams, at the moment it appears to require using the same tool (BOUML). I have not spent much time on this, and others are welcome (encouraged;-) to jump in and add to the resources. - thomas And I completely forgot to mention - thanks to Eric Browne who did the vast majority of the model definition work. ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/4d89b602/attachment.html
13606 revisited - list proposal
Hi Thomas, Indeed, our practice confirms the need for a simpler form of single event observations. We are compensating for this with our Java TDO generator that detects history instances with event count constrained to single and merges a history and event objects into one event-history object that sort of represents a union of both classes. This way our developers end up with a less boiler-plate code to deal with and the rm model is preserved. best regards, Saso Rutar Date: Fri, 23 Mar 2012 14:25:34 + From: Thomas Bealethomas.beale at oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: 13606 revisited - list proposal Message-ID:4F6C87DE.8090004 at oceaninformatics.com Content-Type: text/plain; charset=iso-8859-1; Format=flowed In the thread below, Pablo asked whether Action should have as its data not just an ItemStructure but a History, like Observation. Does anyone else have evidence supporting this need? A related question is: is there a need for an Observation type that only has one Event in it, i.e. one time-point? Obviously quite a few observations in real life, including 'patient story' are of this form. Our original motivation was to make all Observation data structures the same, hence the current data structures. Introducing more types makes code more complex and therefore error-prone, but generally makes data simpler/smaller overall. thoughts? - thomas On 13/02/2012 21:31, pablo pazos wrote: Hi Thomas, Sorry for the delay, I'm working on several projects right now and have little time to follow discussion here. I'm also thinking about the ENTRY model, to lift up the data/description attributes from all entry subclasses to the ENTRY, to have a ENTRY.data:DATA_STRUCTURE attribute, so all subentries could define the data as ITEM_STRUCTURE or as a HISTORY. We did think about this a long time ago, but it did not seem useful. But I assume you are thinking of doing it because you want to make ENTRY a concrete class which could have 'any' structure. Nope, is because I see a common pattern on concreate ENTRY subclases. In theory doing this breaks a basic modelling rule, which is that a superclass whose descendants define the possible data space should not itself be concrete. I think this is not the case, having a ENTRY.data : DATA_STRUCTURE is in fact a more specific ENTRY class, but is still a generic one that could be specialized in many ways. In my (maybe biased) experience, all subclasses from ENTRY would make use of this attribute since a structure is needed to record information. The argument here I suppose is that we want to build in a 13606-style 'uncommitted' kind of ENTRY. In fact we already have this - it's currently called GENERIC_ENTRY http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html. This doesn't get used at the moment (although it has been there for years), and if we want to make it a subtype of ENTRY, that could be done. The main thing to solve I guess is the conversion of any of the specific openEHR kinds of ENTRY into a generic ENTRY structure defined by 13606. This can actually be formally specified by an algorithm. It doesn't require that the parent abstract ENTRY become concrete either. I am unclear if there are other reasons to make the ENTRY parent type concrete, to mimic 13606 ENTRY, rather than simply move GENERIC_ENTRY to be a subtype, which seems more obvious to me. Maybe to have the flexibility to define ACTIONS and other entries to have a data attribute of class ITEM_STRUCTURE or HISTORY to track time of events instead of inventing DV_DATE/DV_DATETIME ELEMENTs on ACTION/EVALUATION/INSTRUCTION archetypes is a good idea. What do you think? Well then I think we risk making the model ambiguous, and different people will use such flexible structures to do the same thing in different ways, which was the thing we were originally trying to avoid. I disagree here, the model semantics could be defined in the specs. My argument is that we are giving a more flexible IM is adding flexibility (not ambiguity) to archetypes, and giving knowledge modelers more options. Then, when they create a concrete archetype, there is no ambiguity because an archetype models a concept in one way, and if abstract classes are used in archetypes, the archetype needs specialization to make is usable on a real environment (software can't instantiate abstract classes, and could not make the decision between using subclass A or subclass B). The HISTORY class is very nicely designed to represent complex time-series data that has the same protocol and was captured in an uinterrupted series. It does not try to model sequences of different types of data - in that case, you just have multiple observations. I totally agree. It deal well with point values, averaged interval values, max, min,
13606 revisited - list proposal
. __**_ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/**mailman/listinfo/openehr-**technicalhttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/a94ad09b/attachment-0001.html
Suggestion to replace use of generics with inheritence in future RM versions
David, This http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateA.2ModifyCLUSTERtohavelocalvalue is what I would realistically propose, for the CLUSTER/ELEMENT part of the model. I will also post a version with integrated changes - this change, plus the simplification of ITEM_STRUCTURE etc. - thomas On 22/03/2012 13:56, David Moner wrote: 2012/3/22 Thomas Beale thomas.beale at oceaninformatics.com mailto:thomas.beale at oceaninformatics.com Instead, I think we should re-invigorate the Java Implementation Technology Spec, that Rong wrote originally some years ago, to provide Java implementation guidance for issues like this. All target implementation technologies have their issues; if we keep hacking the primary specfication model to suit all of them, we will no longer have any clear statement at all of what we really wanted in the first place, and it would in any case probably be a very weak model, once you accommodate no generics, no multiple inheritance, no typing, ! I was exaclty thinking about this while seeing this proposal for the ITEM_STRUCTURE change to a VALUE_CLUSTER: http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateA.1AddVALUECLUSTER%2CRemoveITEMSTRUCTUREtypes It is an example of multiple inheritance not supported by Java and some other languages. I agree with you that a programming language limitation cannot be imposed to a good model design, but it is also true that for example Java is not a minor language to forget of. There should be a balance between what it is perfectly modelled and what can be implemented by most. * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/a0dd4fa6/attachment.html
Suggestion to replace use of generics with inheritence in future RM versions
Two further variants are now up, with the second http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateA.4MakeITEMthefocal%27datastructure%27class containing the more radical changes. Comments welcome. - thomas On 26/03/2012 13:41, Thomas Beale wrote: David, This http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateA.2ModifyCLUSTERtohavelocalvalue is what I would realistically propose, for the CLUSTER/ELEMENT part of the model. I will also post a version with integrated changes - this change, plus the simplification of ITEM_STRUCTURE etc. - thomas * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/9eeb946f/attachment.html
Suggestion to replace use of generics with inheritence in future RM versions
On 23/03/2012 12:09, Heath Frankel wrote: I know every developer can do it better than the next but any developer can do it better than a tool. How true. That statement should be on the wall of every UML tool vendor's office! - thomas
Suggestion to replace use of generics with inheritence in future RM versions
If any developer would do better than a tool, why would anybody write tools in the first place? On Mon, Mar 26, 2012 at 3:26 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 23/03/2012 12:09, Heath Frankel wrote: I know every developer can do it better than the next but any developer can do it better than a tool. How true. That statement should be on the wall of every UML tool vendor's office! - thomas __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/04076842/attachment.html
13606 revisited - list proposal
semantic arguments for State. Let the debate begin!! Ian* * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/c0c87d63/attachment-0001.html -- next part -- A non-text attachment was scrubbed... Name: ebgbhgab.png Type: image/png Size: 43856 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/c0c87d63/attachment-0002.png -- next part -- A non-text attachment was scrubbed... Name: hjgjjiaj.png Type: image/png Size: 9048 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/c0c87d63/attachment-0003.png
Suggestion to replace use of generics with inheritence in future RM versions
Developers are expensive, tools are reusable :D -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 26 Mar 2012 15:43:15 +0100 Subject: Re: Suggestion to replace use of generics with inheritence in future RM versions From: serefari...@kurumsalteknoloji.com To: openehr-technical at lists.openehr.org If any developer would do better than a tool, why would anybody write tools in the first place? On Mon, Mar 26, 2012 at 3:26 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 23/03/2012 12:09, Heath Frankel wrote: I know every developer can do it better than the next but any developer can do it better than a tool. How true. That statement should be on the wall of every UML tool vendor's office! - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/05269231/attachment.html
13606 revisited - list proposal
not saying we need to do the changes, what I say is lets discuss if we can improve the model in some way, analize the pros and cons, and write down a decision. I mean: we need to try to not leave these kind of discussions die on the maillist, this things are valuable assets that could be explored/exploted in the future. Another question of time comes up with EVALUATION - e.g. the diagnosis archetype. This is full of times, and tries to follow a disease course model. Currently there is no RM class for this, but if a standardised temporal disease model were agreed across medicine, I suppose there is no reason why not. But it also is not a simple HISTORY - it is more 'bumpy'... and I don't know if there is any agreed standard model of this. Maybe is something like a HISTORYENTRY or a HISTORYCOMPOSITION? -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/7d3d8590/attachment-0001.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/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/7d3d8590/attachment-0001.jpg
13606 revisited - list proposal
On 26/03/2012 19:49, pablo pazos wrote: Hi Thomas, A while ago, we gave this issue a big thought when designing the EHRGen framework. Periodic event records are needed when recording certain studies and when monitoring a patient, but this can be recorded as single point events, and using a query to get all the points in a series. it can but that's very inefficient, and doesn't correctly represent what is happening, when you are talking about multiple samples in a series, e.g. coming from vital signs monitors, orthostatic BP, apgar, and many others. From the GUI perspective is very difficult to record periodic events, because you have to login, select a patient, select a record, select the section of that record that contains the periodic data, enter a new item to the time series. and presumably enter another, and another. That doesn't sound like a problem - it's how normal GUI for Apgar and multi-sample manual BP collection work. Don't forget, we are talking about time series in the seconds to minutes domain here. Although Glucose tolerance test data would make more sense to be entered as one time series, after the fact. The other option is to have the patient's record always open, and that is not possible in all scenarios (for technical or security reasons). well ifyou are talking about long period of time, like repeated nursing observations, you should be committing those 1 sample at a time. In the other hand, in the majority of cases of clinical record through a GUI, the data is recorded as a single point event, e.g. at a patient visit. So we design the EHRGen just to use point events, and if you want to record a series of events, a service should be provided to get the data from other systems (e.g. a LAB system), but not from the GUI. that and vital signs monitors are certainly a common source of time-based data. But whether the source of the data is the GUI or somewhere else doesn't change the semantics of the model, or the need for it. Like I said elsewhere, I have no problem with adding a single-event Observation as well. But having only that will completely cripple many hospital apps and efficient data representation and querying related to this data. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/09b309e7/attachment.html
