OCL (was: RE: Introducing myself + question)
Instead one is forced to write: context Person inv: wife-notEmpty() implies wife.gender = Gender::female which is not only counter-intuitive (Person.wife is not defined as a Set of anything, it is defined as a Person), but seems wrong because there is no formal connection between whatever Set the expression wife- refers to and the underlying model, so how can one say anything about what the membership of this set might imply for the value of the Person at the other end of the wife association? but it's worse than this in practice. if wife is null, therefore wife-isEmpty is true. Therefore wife.Gender = Gender::female is true, because there is no wife in the list that breaks this constraint. This is not intuitive but is an inevitable conclusion from the use of wife-notEmpty() to specify that wife != null. Obviously it's safe if you write inv: not (wife-notEmpty()) and (wife.gender = Gender::female) but most people wouldn't think of doing this and would simply write inv: wife.gender = Gender::female expecting that this would only be true if wife.Gender actually was Gender::female Grahame - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Introducing myself + question
Rafal We have seen this coming for some time and I would point out a few things that seem clear: 1. That queries can be based across a number of EHRs or within one - the oprimisation issues are somewhat different 2. That queries may return rows of data (like in current RDBS) or lumps of data for viewing - 'data queries' or 'clinical queries' 3. Within each EHR the query may be limited to a specific composition (transaction) type (ie and archetyped transaction) 4. Within transactions the query may be limited to specific organisers All of these queries outlined to this point will return disparate data (even if they are all entries) and will be very difficult to process - very useful clinically. Examples are: What examinations have been done in antenatal attendances What therapies have been planned or implemented for people in outpatients in the last week Then we have queries that get to the data level - these will need to return known data points in the entries. These will be accessed via paths. When building these queries the enquirer will be asked which archetypes and which paths (design time or run time) to return. This would enable us to get a row of data such as: For all patients who have had their blood pressure measured in antenatal clinic - return the systolic and diastolic blood pressures and their weight. For all patients who are on beclomethasone inhalers return the name and dose of inhaled steroid and their peak flow measurements for the past year. You will see that until the query addresses and entry archetype (like a table in RDBS) you will only return information that is clinically readable but difficult to process. The entries then become the equivalent of the tables - the paths are the equivalent of the columns. Some efficiencies come from running queries on one patient - when the query engine can use the archetypes in that EHR as the set of archetypes on which to query - you don't have to look if they are not there. Also, archetypes become the bases of indexes. Cheers, Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Thomas Beale Sent: Sunday, 23 March 2003 11:24 PM To: Rafal Szczesniak Cc: openehr-technical at openehr.org Subject: Re: Introducing myself + question if you are thinking of specific querying language - I would agree - we can already see that the use of archetypes at runtime changes how queries are written and does require some new kind of language. We have been experimenting on this, and are working on it... - thomas beale Rafal Szczesniak wrote: On Sun, Mar 23, 2003 at 02:56:40PM +1000, Thomas Beale wrote: Another issue which I think is more important than language is runtime interfaces. Components written in many languages can be interfaced by COM, and presumbly, .Net infrastructure; most languages can produce DLLs for Windows and .so or other kinds of libraries for the unixes. The ability to interface trusted components is key to building large systems without having to do everything yourself. Another interesting thing is that developing openEHR systems might reveal the need of specific language to operate on. Similiar to what SQL is for relational databases today. This could be also a mean to standarise communication between EHR systems. cheers, -- .. Deep Thought Informatics Pty Ltd mailto:thomas at deepthought.com.au openEHR - http://www.openEHR.org Archetypes - http://www.deepthought.com.au/it/archetypes.html Community Informatics - http://www.deepthought.com.au/ci/rii/Output/mainTOC.html .. - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
OCL (was: RE: Introducing myself + question)
Hi Pete, Pete Rivett wrote: Hi Thomas, I appreciate the trouble you've taken to evaluate OCL, and think several of the issues are worthy of consideration. Just for your information, and for others on this list, the latest version of the OCL 2.0 submission is 1.6 (as opposed to 1.0 you reviewed which is 2.5 years old!). This is due to be adopted later today, as it happens. I reviewed the version I did because it was the one passed around (or referred to with a URL, I forget which) recently by HL7...Can you provide a URL to the latest submission? Despite the imminent adoption it is still possible to submit issues to OMG's Finalization Task Force which is responsible for considering implementation and other issues prior to the standard becoming officially 'Finalized' and 'Available'. To do this just send an email to issues at omg.org, or fill in the form at the OMG web site http://www.omg.org/technology/issuesform.htm. I guess I could do this, but I don't imagine they are going to be interested in anything but tiny details by now... In general OMG attempts to be an open and responsive organization and anyone (not only members) can raise issues against any OMG specification. Though OMG can only address issues if it know about them - so I would sincerely encourage people to use the mechanisms available. my general impression of the OMG, and experience with members of HDTF certainly supports, this, and I think that OMG is overall an organisation with good process, timeliness, and a good track recordin a way it is a pity that HDTF (health domain task force) has little support at the moment (or so I've been told) since the OMG process is definitely superior to that in other standards organisations. But - that's a conversatino for another day/mailing list! However, while I must admit a bias as one of the submitters of OCL 2.0, I would disagree that the semantics are 'quite broken'. I assume the following from the review is intended to illustrate 'broken semantics': --- In section 2.5.4, subsection Navigation over Associations with Multiplicity Zero or One it is stated that ...a single object can be used as a set as well. It then behaves as if it is a Set containing the single object I had to read this a few times to believe it. While there is clearly a drive to make everything somehow the same for the purpose of querying, there is no way a formal type system can be respected if such liberties are taken - the basis of correct specifications disappears. There is no way, for example, that PERSON.manager: PERSON can act as a Set if has been specified as a PERSON - these are two distinct types, and have nothing to do with each other. --- yes, this is the major problem I see. It is quite pervasive as well. I view treating a single object as a set as a convenient implicit 'cast' operation. Most programming languages have such a thing: e.g. to allow an Integer to be treated as a Real. well actually, this capability is not casting, but type promotion, and only applies (as far as I know) to numeric types to enable infix/prefix arithmetic and relational operator semantics (e.g. 3.0 + 1 and 3.1415926 2.171828) to be evaluated. Type promotion of numeric types is quite a specific feature, and is done by compilers, not programmers. Casting on the other hand is almost always a dangerous and bad thing. I can't think of any code where it was justified, where the language itself was not already the problem, e.g. by not having generic classes, the lack of whcih is the main reason for programmers being forced to cast. But the real problem is that turning an Integer into a Real is reasonable: they have almost the same interface. Turning PERSON into SETPERSON makes no sense - there are no similarities between the interface of a T and a SetT in general. No common programming languages support this natively (I'm sure there is some academic language which does), and if programmers start doing such casts, they will get into serious trouble. Secondly, this feature of OCL seems to prevent simple statements like: context PERSON inv: employer null This is the most common kind of statement one wants to make in invariants, pre- and post-conditions. I cannot imagine why it is not available (maybe it is - it wasn't apparent to me in the spec, nor to the authors of another report on OCL which I have seen). And if really concerned about the difference OCL has capabilities to distinguish an object from a set. do you mean the dot and arrow notation? Finally, with regard to implementability, there are several implementations of OCL in existence (currently of OCL 1, though OCL 2 does not introduce any radically new capabilities). These exist in both commercial products (e.g. BoldSoft, now part of Borland) and university/research projects (e.g. Kent Modelling Framework - www.cs.ukc.ac.uk/kmf). this is good to know. However, I feel it is a real pity to have this problem of SetT/T in OCL - I think
Introducing myself + question
Tom Culpepper wrote: I again would like to reiterate may opinion on this list concerning the modeling of Healthcare. The business of Healthcare (both Clinical and Administrative) needs to be modeled in a language, platform and operating system independent manner. This will provide the opportunity for folks to provide implementations that can be used across the widest spectrum while leveraging legacy systems. One such universal modeling language is UML (Unified Modeling Language) and the OPEN technology that is making this a reality comes from the Object Management Group (www.omg.com http://www.omg.com/) MDA (Model Driven Architecture). well as you'll see in the specs there is no language-dependent stuff - it's all UML. The only slight problem at the moment is that OCL has some quite broken semantics which would prevent it being used properly for the constraints, but even then maybe we just have to go with it. In the specs currently, the constraints are expressed in a first order predicate form very similar to OCL. We'll have to fix tis eventually, but as almost no-one except Eiffel people can implement the statements directly anyway, it doesn't seem a big concern... Making a decision to develop models that force people to use C, C++, Java, Effiel, Microsoft NT, Unix, MVS, or proprietary mechanisms will only hamper IT efforts for interoperable solutions. right. I don't know why we get into these discussions really - the specifications are competely language independent (I'd have to say even moreso than OMG actually - IDL is actually quite C++/C oriented, but that's history - let's not waste our breath on it now!) I also concur with David Forsland in the use of the Object Constraint Language. Tom, I'm interested in what you think about the review I have done. See http://www.deepthought.com.au/it/ocl_review.html. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
