Archetype versioning on CKM
2011/4/28 Thomas Beale thomas.beale at oceaninformatics.com: On 27/04/2011 10:44, Diego Bosc? wrote: I still don't see the problem If we wait until an archetype is published to care about versions then you will have v2 or v3 archetypes as much, which in my opinion breaks completely versioning purpose. What is the problem with having a v27 archetype? Is it less pretty? it should make no difference, although since the major version number in openEHR is reserved for breaking changes, one would hope that v27 archetypes would never occur. However, v2.0.154 or v3.18.26 could be realistic. We should have no problem with v0.1 or v0.2.1 then... If we have two different systems that communicate and they are referring to different archetypes with the same name then we are throwing away all the supposed semantic interoperability (Not much better than using HL7 v2 messages that use different Z segments). If we want to openEHR to get broader use we can't just tell the people that have been already using archetypes that the archetypes on their projects were not intended to be used or you used them at your own risk. If we want to go that way then we should put at least a warning on the download page of those archetypes. - t ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
Archetype versioning on CKM
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/cfbff873/attachment.html
Archetype versioning on CKM
2011/4/28 Heather Leslie heather.leslie at oceaninformatics.com Hi everyone, I think you are missing some of the further complexity here. There is a definite need for differentiation between draft and published archetypes for which a version number alone is not enough. Currently we are talking only about v1 archetypes and how to manage them, and to a degree it makes sense. We certainly considered using v0.x for drafts but it doesn't solve the downstream problems - once a v1 archetype is published, the non-breaking revisions will become v1.1, 1.2 etc. No problem But when we make a breaking change it becomes v2 (or v3 or v4 or 125), but it needs to be clear that it is v2 *draft* initially and not v2 *published* until we have completed the neccessary collaborative reviews. I see your point and I completely agree with it. Using v0 to denote draft archetypes before going to v1 only solves the first iteration. When moving to v2, v3, etc. we certainly will have drafts and published archetypes for those new versions and we have to manage all them. Even when creating v1.x or v1.x.y archetypes we can need drafts prior to the formal voting/validation/publication of them. Archetypes, as a technical resource (not as a concept definition) need to have unique identifier for each minimal change. We have the archetype revision history but we should also show those changes by changing the identifiers. So, we fall back to the need of rethinking archetype identifiers to include these new requirements or change them into identifiers with no semantics. Or a third option, maybe the best one, to clearly separate between a concept identifier that would be the current identifier and a resource identifier to track every change and to, at least, warn systems that use archetypes that something has changed. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/9cdfe73f/attachment.html
Fwd: [Fwd: Re: Archetype versioning on CKM]
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/143ac7ac/attachment.html
Archetype versioning on CKM
, and describe them in a new issue of the identification specification. We then need to work out an implementation plan, mostly to do with changes to CKM to support the decisions. There are two ways to go about this: * interested parties review the identification spec, and provide feedback * we work out the details on the technical list + wiki via discussion and then update the spec. Key things that need decisions: * do we go with starting at v0 or v1 (I still like v0 because it implies 'you will most likely get burnt by using this archetype in a real system, but have fun and tell us your experience')? * can we agree on the archetype life-cycle states and the idea that a change in state always causes an increment in minor revision number? * how should archetypes be referenced from data? * what system of hashing and signing should be used? - thomas* * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/6eacdbf4/attachment.html
Archetype versioning on CKM
On 28/04/2011 13:15, Heather Leslie wrote: * do we go with starting at v0 or v1 (I still like v0 because it implies 'you will most likely get burnt by using this archetype in a real system, but have fun and tell us your experience')? Some current plans for CKM include recognising the need for alpha archetypes. However the feeling is that these could and should be managed in a connected but separate proposed archetype 'sandpit' - something planned for CKM as a space where we can start archetype collaboration from a very raw concept stage and evolve it in a (potentially) open way. This will enable the current CKM to continue to be the place for 'serious' archetype candidates, open collaboration and appropriate governance (at a level that is deemed appropriate for the status of the archetype - looser for drafts, extremely tight for published). *If* and when the alpha archetypes are mature enough to be reasonable candidates for collaborative review then they can be promoted to the CKM as we know it now - effectively the current CKM drafts. We don't need to do this in the current CKM process * * the separate sandpit seems like a reasonable idea, but archetypes there will still need to be identified, and there will always be someone who will use them - at least in purely research systems - so I think the need for 'v0' doesn't go away... - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/0a22173d/attachment.html
Archetype versioning on CKM
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/6287abf1/attachment.html
Unable to express an unit of measurements in UCUM syntax
hi Leo I have forwarded this question onto the UCUM wizard (Gunther Schadow). It's a pretty good question. Simply allowing the decimal would make the syntax ambiguous, but there's no easy way to do it any other way. Grahame On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo lmoretti at noemalife.com wrote: In cardiology, left ventricular mass (LVM) is often indexed to better identify left ventricular hypertrophy. Possible indexations are: - LVM/BSA (body surface area) - LVM/height - LVM/height^2.7 The first and the latter are often used. The units of measurement of the latter is usually g/m2.7 [gram/(meter^2.7)]. In DV_QUANTITY, units attribute should be expressed in UCUM unit syntax. UCUM doesn't allow not integer exponent (see http://aurora.regenstrief.org/~ucum/ucum.html#section-Syntax-Rules), so I have the problem that I cannot express the units as g/m2.7. Any suggestion to solve this problem!? Best regards leo ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065
Reverse Relations
Hi Bert, On 19/04/2011 11:54, Bert Verhees wrote: Hi, Excuse for the bit complex text below, I don't know how to say it more simple I have a small problem with the way ReverseRelationships are connected to Party in the Demographic RM. Maybe my problem is because of my misunderstanding. The problem is not only conceptual, but it also causes problems in coding (programming) the kernel. The problem is that ReverseRelationships are a Set of LocatableRef. This means that the PartyRelationship has to be stored before it can be added to a party ReverseRelationship list. The PartyRelationship has to be stored because LocatableRef takes a ObjectVersionID as constructor-argument. I presume this is in the Java implementation, since constructors are not defined in the openEHR specifications? Obviously using constructors is not the only possibility, setter routines could also be used. IN any case, creation of identifiers does not rely on persistence; it should be knowable beforehand, so I would expect the use of a constructor to be fine. The conceptual problem is that the ReverseRelationship in this way is defined as a version of a specific PartyRelationship. If the PartyRelationship changes, for example in its details, than the new version is not anymore connected to the target-Party, or this connection needs extra code to restore /(replace the ObjectVersionID in the target-Party ReverseRelationship-set, maybe even create a new version of the PArty, because of a new version in another object, namely the PartyRelationship-object) / the reverse_relationships attribute of PARTY is intended to contain a set of reverse pointers to PARTY_RELATIONSHIPs for which the PARTY is a 'target'. The first thing to note is that the attribute is optional, and you can ignore it if you want. If you use it, it should always contain the current list of PARTY_RELATIONSHIPs for which the PARTY is a 'target'. If any such relationship is changed, then the relevant PARTYs would have to be updated. The problem you point out is that if the change in the PARTY_RELATIONSHIP (taking it from version 3 to 4, let's say) doesn't affect a given PARTY, which is a target of version 3 of the PARTY_RELATIONSHIP, then you are still forced to update the PARTY so that it its reverse_relationships now has the v4 id for the updated PARTY_RELATIONSHIP rather than the v3 id. One way to fix this would be if we were to enable a 'latest' version id that always automatically pointed to the latest version of something. This is defined for openEHR EHR URIs, but not for the type OBJECT_VERSION_ID, used in LOCATABLE_REF. I think a better solution is that PARTY simply does not contain reverse relationships, because it is essentially solving a database indexing problem, which could be better solved by maintaining index objects and/or native indexes, depending on how the demographic model persistence is implemented. // I don't understand why that is, it seems a bad thing which causes extra complexity. More logically would seem to me to connect the UID of to the list ReverseRelationships in the target Party, instead of the ObjectVersionID. that would probably risk the reverse_relationships attribute getting out of data quickly and containing wrong information, unless the implementation meticulously checked whether the validity was always maintained or not. I would be interested to know what other experience there is with this attribute; my suspicion is that it should be deprecated. - thomas* * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/433f3de8/attachment.html
Unable to express an unit of measurements in UCUM syntax
Hi there are a lots of scientific publications treating the indexations of left ventricular mass (LVM). I can link some abstracts, but the whole PDF documents are not public: - http://www.nature.com/jhh/journal/v23/n11/full/jhh200916a.html - http://www.ncbi.nlm.nih.gov/pubmed/11729247 or here https://www.stanford.edu/group/ccm_echocardio/cgi-bin/mediawiki/index.php/Left_ventricle_wall_thickness It can be used to detect left ventricular hypertrophy. You can google mass/height^2.7 to find more references. Thanks for your help. leo Grahame Grieve-3 wrote: Hi Leo Can you please provide some references to show the use of height^2.7? Grahame On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo lmoretti at noemalife.com wrote: In cardiology, left ventricular mass (LVM) is often indexed to better identify left ventricular hypertrophy. Possible indexations are: - LVM/BSA (body surface area) - LVM/height - LVM/height^2.7 The first and the latter are often used. The units of measurement of the latter is usually g/m2.7 [gram/(meter^2.7)]. In DV_QUANTITY, units attribute should be expressed in UCUM unit syntax. UCUM doesn't allow not integer exponent (see http://aurora.regenstrief.org/~ucum/ucum.html#section-Syntax-Rules), so I have the problem that I cannot express the units as g/m2.7. Any suggestion to solve this problem!? Best regards leo ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- View this message in context: http://old.nabble.com/Unable-to-express-an-unit-of-measurements-in-UCUM-syntax-tp31494533p31497302.html Sent from the openehr-technical mailing list archive at Nabble.com.
openEHR artifact namespace identifiers
On 08/04/2011 01:49, Heath Frankel wrote: Thomas, Your proposed changes to the archetype Identifiers and governance actually aligns with the same management and inferencing requirements as OIDs, the only benefit left is the readability, but even that is becoming hard to do with the additional namespaces and delimiters. In addition, having meaningful IDs and deriving meaning from IDs is counter to what good practice in terminology identifier management. for atomic concepts a la SNOMED, meaningless identifiers make sense; for complex artefacts like programming language source files - of which archetypes are an example, they don't really - they just obscures meaning from developers. Meaningless identifiers of the Guid variety make sense for deployed versions of these artefacts - i.e. generated template OPTs, assemblies etc. Where identification really matters is a) in data and b) in deployed software artefacts that were generated from templates archetypes. The future may well be to do as David Moner (I think, or maybe Diego, can't remember now) said - to create archetype meta-data attributes to carry the pieces of the id, and generate the strings that we currently use as ids when and as needed. Attaching Guids to source archetypes can also be done obviously, but I think for source artefacts, Oids provide little gain and a lot of pain. - thomas * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/ab48c497/attachment.html
