ADL internal references change proposal
Hello to everybody.
We have detected an issue in the ADL grammar related to the node_id (at
value) of Internal References. An Internal Reference node, as any other
C_OBJECT, inherits the node_id attribute. But its ADL grammar does not allow
to define this value in a textual representation.
archetype_internal_ref:
SYM_USE_NODE type_identifier c_occurrences object_path
| SYM_USE_NODE type_identifier error
We think it is necessary to allow the introduction of this information in
some cases. When we re-use an internal data structure, we are maybe also
changing its meaning. For example, looking at the example provided in the
ADL 1.4 document, page 59.
CONTACT [at0004] ? { -- home contact
purpose ? {-- etc --}
addresses cardinality ? {0..*} ? {
ADDRESS [at0005] ? { -- phone
type ? {-- etc --}
details ? {-- etc --}
}
ADDRESS [at0006] ? { -- fax
type ? {-- etc --}
details ? {-- etc --}
}
ADDRESS [at0007] ? { -- email
type ? {-- etc --}
details ? {-- etc --}
}
}
}
CONTACT [at0008] ? { -- work contact
purpose ? {-- etc --}
addresses cardinality ? {0..*} ? {
use_node ADDRESS /contacts[at0004]/addresses[at0005] -- phone
use_node ADDRESS /contacts[at0004]/addresses[at0006] -- fax
use_node ADDRESS /contacts[at0004]/addresses[at0007] -- email
}
}
}
We re-use nodes at0005, at0006 and at0007 but we do not assign a new at
code to them. Structurally, this is correct, but not semantically (i.e. we
reuse structure but not meaning). It is not the same a home phone number
than a work phone number. In fact, SNOMED uses diferent codes for each
case: a Patient home telephone number (code 429697006) and a
javascript:action(27)Patient work telephone number (code 428843000).
To sum up, it would be necessary to change the ADL grammar to support the
use of new definitions of term_codes in the archetype internal references,
something like:
use_node ADDRESS*[at1234]* /contacts[at0004]/addresses[at0005] -- phone
Finally, it is necessary to remember that the archetype slot (which is a
very similar use case) allows this kind of definition.
c_archetype_slot_id:
SYM_ALLOW_ARCHETYPE type_identifier
| SYM_ALLOW_ARCHETYPE type_identifier *V_LOCAL_TERM_CODE_REF*
| SYM_ALLOW_ARCHETYPE error
--
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/20090209/d47e07fc/attachment.html
CQuantityItem.units not empty
Hi all.
I?m working in the archetype validation alghoritm of the zilics models (more
on this thread --
http://www.openehr.org/mailarchives/ref_impl_java/msg00975.html).
I ran into a little problem, and I?d like to hear your thoughts.
The specification for the C_QUANTITY_ITEM class states that the units
field is valid when:
units_valid: units /= Void and not units.is_empty, in other (java) words:
units != null units.size() 0
Ocean?s Archetype editor lets you create a Quantity Item as a Qualified
real, without any units.
The ADL it generates for such an item is like:
ELEMENT[at0005] occurrences matches {0..1} matches { -- INR
value matches {
C_DV_QUANTITY
property = [openehr::380]
list =
[1] =
units =
magnitude = |=0.0|
precision = |0|
}
}
For such an archetype, validation fails because the parsed Archetype object
will have a CQuantityItem object having units = [empty list]
So, which one is wrong? The archetype or the validation alghorithm?
Should I just avoid creating archetypes with Quantity items with no units?
If so, should Archetype editor prevent the user from creating such an item?
Cheers!
Tony L?mpada
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090209/3b335961/attachment.html
Future-proof at risk! was: RM Versions
ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090209/6090d2fc/attachment.asc
ADL internal references change proposal
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090209/dee5dbd7/attachment.html -- next part -- A non-text attachment was scrubbed... Name: OceanC_small.png Type: image/png Size: 4972 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090209/dee5dbd7/attachment.png
CQuantityItem.units not empty
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090209/b07f673d/attachment.html -- next part -- A non-text attachment was scrubbed... Name: OceanC_small.png Type: image/png Size: 4972 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090209/b07f673d/attachment.png
Future-proof at risk! was: RM Versions
Tim Cook wrote: There are VERY specific guidelines as to what and what does not constitute various archetype version changes. Maybe/maybe not these should be reviewed in reference to RM versions? they are under review, that is for sure - we can discuss this a bit more when the template ADL 1.5 specs move on a bit more. But the rules are pretty stable even now, mostly based on what ADL1.5 says 'conformance' means. But lets leave this to another thread... Since we all have very good crystal balls. We can see a future where at RM version 2.5 there are significant differences to RM version 1.0.2. well - there are also rules about the RM as well. Ideally, even over major releases, e.g. 1.x - 2.x, the core of the current reference model will remain backward compatible, meaning: * new attributes could potentially be added, but they must be optional * mandatory attributes can't be removed (later software might sometimes see a data item in old data corresponding to an optional attribute that was removed) * attributes could only be changed in such a way as to make them a broader constraint, e.g. a mandatory attribute could be made optional (later software will handle older data, which is the effect we want) These rules are intended to be hard and fast across sub-major and minor releases, but I suspect they will apply over major releases as well. If they didn't, then all we can say is that archetypes are only guaranteed to work within a given major release, e.g. 1.x - which might not be true for many archetypes, even if there were breaking changes, if those archetypes did not happen to reference the broken part of the model. The reason I think we realistically have to allow breaking changes across major releases is not due to the core models of today, which seem pretty safe. It is new additions with which we have less experience, e.g. two areas I can see being added to the RM are process/workflow, and 'study' data (i.e. the CDISC idea). I don't imagine we will get these right first go, so we would need to allow them to be fixed over a major release. However; we have Mary in rural Montana USA, a patient a Dr. Jones's office (believing strongly in future proof) and she moves to a new city; let's say Atlanta, GA. Where Dr. Brown (ALSO! believing strongly in future proof) has been on top of things and is now at RM version 2.5. Well, Dr. Brown gets Mary's record from Dr. Jones and discovers that some of the archetypes that were built 15 years ago in 1.0.2 RM just simply do not display or worse yet cause unknown type errors and his application(s) crashes. Future Proof? Hardly! well - it depends on the position we take on whether breaking changes are allowed or not. Doesn't seem much different from the migrating SQL data base schema problem does it? probably somewhat better - you touch almost anything in a relational database and the software breaks So I believe that we as a community should take multiple courses. I want to emphasize that we should take THEM ALL! First: an archetype tool developer MUST record the RM that an archetype was built against. Let's say RM=['1.0.1'] I don't object in principle of course - my question earlier was simply: how do you know which minor version to put? The archetype may have been built during the reign of 1.0.1, but gets published at 1.0.5 (4 minor versions got done during one week maybe). According to the logic above, only the major version number should be recorded (okay so I apologize for my Python syntax, but it's easy to read). Second: An archetype is edited (whether it's version changes or not) against a tool using RM 1.0.2. The RM = is now RM=['1.0.1,'1.0.2] do you mean a copy is edited? If multiple copies are edited by different tools (including the definitive copies in online repositories) some will get the 1.0.2 added, some won't, due to older tools. Then you have multiple copies of the same archetype with different meta-data. And plus, a publishing event is forced for every archetype whenever a new minor reference model release is made. At some point this archetype has now been validated against 2 RM versions. It should work with both RM versions and the consumer (application developer knows it). Third: The application developer has a choice to make. Either read the list and support backwards compatibility based on the last known RM version or simply be NON-FUTURE-PROOF and reject the data. At the very least, the archetype contains the information needed to let the application know what it expects in order to be rendered and processed. So in essence, I TOTALLY disagree with Tom's statement: so let me adjust that - depending on the rule we set in the community for changes over major releases, we should record the RM major release number only in an archetype. Any takers? - thomas beale
Future-proof at risk! was: RM Versions
If different versions of the OpenEHR (or any other model) are available on an application they should be used as different RM, because usually the changes in the reference model can make newly created archetypes (1.0.2 in your example) not to parse with older RM parsers (1.0.1) The currently specification of archetype id can handle this already perfectly. An archetype like openEHR-EHR-INSTRUCTION.medication.v1 will turn into openEHR-EHR1_0_2-INSTRUCTION.medication.v1 (and using underscores is only because currently the parser won't allow dots on the id) If dots were allowed you could rewrite this as openEHR-EHR1.0.2-INSTRUCTION.medication.v1 as opposite to openEHR-EHR1.0.1-INSTRUCTION.medication.v1 that would only parse with 1.0.1 parser Regards 2009/2/9 Tim Cook timothywayne.cook at gmail.com: Okay, Maybe the subject line is a little melodramatic. :-) But we do have a situation and a good bit of this email (along with your consultations) will be placed as a Problem Report (PR) on the openEHR.org website. My point of view is that we have a multi-level modeling environment and therefore we have a multi-level problem solving environment. It must ALL work together. Archetype designers and application developers. I'll be a bit shallow in this email and will not look up specific instances. But there are place(s) within the RM where the RM version is recorded. The archetype tools should record this information in the archetype saying that this version of THIS archetype was built against a specific openEHR RM version. There are VERY specific guidelines as to what and what does not constitute various archetype version changes. Maybe/maybe not these should be reviewed in reference to RM versions? Since we all have very good crystal balls. We can see a future where at RM version 2.5 there are significant differences to RM version 1.0.2. However; we have Mary in rural Montana USA, a patient a Dr. Jones's office (believing strongly in future proof) and she moves to a new city; let's say Atlanta, GA. Where Dr. Brown (ALSO! believing strongly in future proof) has been on top of things and is now at RM version 2.5. Well, Dr. Brown gets Mary's record from Dr. Jones and discovers that some of the archetypes that were built 15 years ago in 1.0.2 RM just simply do not display or worse yet cause unknown type errors and his application(s) crashes. Future Proof? Hardly! Doesn't seem much different from the migrating SQL data base schema problem does it? So I believe that we as a community should take multiple courses. I want to emphasize that we should take THEM ALL! First: an archetype tool developer MUST record the RM that an archetype was built against. Let's say RM=['1.0.1'] (okay so I apologize for my Python syntax, but it's easy to read). Second: An archetype is edited (whether it's version changes or not) against a tool using RM 1.0.2. The RM = is now RM=['1.0.1,'1.0.2] At some point this archetype has now been validated against 2 RM versions. It should work with both RM versions and the consumer (application developer knows it). Third: The application developer has a choice to make. Either read the list and support backwards compatibility based on the last known RM version or simply be NON-FUTURE-PROOF and reject the data. At the very least, the archetype contains the information needed to let the application know what it expects in order to be rendered and processed. So in essence, I TOTALLY disagree with Tom's statement: I don't mind including the release number of openEHR when the archetype was first released, but I don't see how it can be useful information. Sorry Tom; if it's put in a list, I can see EVERY reason why it is useful information. The openEHR documentation is VERY VERY VERY good. There is no reason that an implementer could possibly accommodate multiple RM versions. Regards, Tim On Sun, 2009-02-08 at 11:03 +, Thomas Beale wrote: Sam Heard wrote: Hi All I would suggest that we have a very strong backwardly compatible notion on each reference model and do not do anything that would invalidate current archetypes in RM 1.x This would mean that we only had to record the highest level version that an archetype was compatible with in the archetype RM 1.0 and leave it at that. I am sure people working in the environment would like such an approach. It means we have two rules: All archetypes of the same version are compatible semantically All archetypes work with the reference model version (1,2 etc) and go on being compatible. Cheers, Sam *I still have not see a solution to the basic problem that if we record a compatibility release(s) _inside_ the archetype, then whenever a new release of openEHR comes out, thousands of archetypes would be updated to reflect the new release number. If this is not done, then those archetypes will over time
Future-proof at risk! was: RM Versions
Let's say RM=['1.0.1'] (okay so I apologize for my Python syntax, but it's easy to read). Second: An archetype is edited (whether it's version changes or not) against a tool using RM 1.0.2. The RM = is now RM=['1.0.1,'1.0.2] As I wrote before, if the choice will be that there will be an internal attribute, like you propose, it will be difficult, or in some systems even impossible, to maintain archetypes with the same name but targeted to different RM-versions. So I would suggest to add the RM-version attribute to the ArchetypeID. Bert
