Possible unknown issue with Archetype Editor
Athanasios Anastasiou wrote: > Is there a known problem with the following archetypes? > openEHR-DEMOGRAPHIC-CLUSTER.individual_credentials_iso.v1 > openEHR-DEMOGRAPHIC-CLUSTER.person_additional_data_br.v1 > openEHR-DEMOGRAPHIC-CLUSTER.person_birth_data.v1 > > If not, could there be something with the Archetype Editor? It refuses to > load these archetypes properly whether it's from the "Open from web" option > or by trying to open an ADL downloaded straight from the CKM. Hi Athanasios, Definitely a known issue ;-) The Archetype Editor has only ever worked with the openEHR-EHR reference model. It was always planned to add support for openEHR-DEMOGRAPHIC, but improving the support for openEHR-EHR has always been a bigger priority. You would be able to load these archetypes in the ADL Workbench, but it doesn't have editing capability. ADL Workbench can validate the archetypes, however, which is useful if you have edited the ADL in a text editor. Peter
Issue (probably known) with ADL Workbench
Hi Carlos Welcome to openEHR. This is a known issue, not with the Workbench but with the archetype itself. This is pretty old and breaks a validation rule that was not enforced properly in the Archetype Editor in the past. I have actually fixed or worked around most of the validation errors that AWB reports but have not had time to commit the fixes to CKM yet. As soon as I have a proper web connect I will do so at least for that archetype. The problem is a bit obscure for an openEHR newbie but is related to a bit of ADL syntax that is not currently supported in the Archetype Editor but which is required if multiple constraints of the same datatype are applied to a single element. You should also be aware that our intention is to replace the current CKM medication archetype with others based on the NEHTA medication archetypes. Ian Dr Ian McNicoll Clinical modelling consultant Ocean Informatics Mobile +44 (0) 775 209 7859 Skype imcnicoll On 13 Sep 2012, at 12:00, Carlos Cavero Barca wrote: > >Hi all, > >I'm quite new in openEHR, testing last released version of ADL > workbench I received an error (ERROR line 87 [last cADL token = > V_C_DOMAIN_TYPE]: (VACSIT) cannot add C_DV_QUANTITY object with > rm_type_name=DV_QUANTITY to singly-valued attribute value because > attribute already has child with same RM type) when I tried to load the > openEHR-HER-ITEM_TREE.medication.v1.adl (draft version). I don't know if > this is known or unknown but just in case. > >If I remove from line 73 to line 98 (C_DV_QUANTITY multiple > references, just leaving one of them) the archetype is perfectly loaded. > The same happened with > openEHR-EHR-ITEM_TREE.medication-formulation.v1.adl. In this case the > C_DV_QUANTITY values are empty and you need to include values on them. > >Thanks and regards. >Carlos. > -- > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive > this e-mail in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos > group liability cannot be triggered for the message content. Although > the sender endeavours to maintain a computer virus-free network, > the sender does not warrant that this transmission is virus-free and > will not be liable for any damages resulting from any virus transmitted. > > Este mensaje y los ficheros adjuntos pueden contener informacion confidencial > destinada solamente a la(s) persona(s) mencionadas anteriormente > pueden estar protegidos por secreto profesional. > Si usted recibe este correo electronico por error, gracias por informar > inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos > no se hace responsable por su contenido. Su contenido no constituye ningun > compromiso para el grupo Atos, salvo ratificacion escrita por ambas partes. > Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor > no puede garantizar nada al respecto y no sera responsable de cualesquiera > danos que puedan resultar de una transmision de virus. > -- > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Possible unknown issue with Archetype Editor
Hi Athanasios The demographic archetypes were built by Brazilian colleagues who did some of the editing manually and also made use of the LinkEHR archetype editor. It is actually quite easy to edit the DEMOGRAPHIC Cluster archetypes in the ocean editor by hacking the archetypeid to EHR-CLUSTER and then changing it back again after using AE. Ian Dr Ian McNicoll Clinical modelling consultant Ocean Informatics Mobile +44 (0) 775 209 7859 Skype imcnicoll On 13 Sep 2012, at 11:11, Athanasios Anastasiou wrote: > Hello Peter and Diego > > Thank you very much for the quick responses. I did briefly go through the > structures to spot the differences and i am really glad to see that someone > has already done this :-) > > Anyway, i thought that it was strange for these to appear on the CKM without > loading properly through the AE (otherwise how where they composed?) but > after the responses it makes sense. > > All the best > Athanasios Anastasiou > > > > On 13/09/2012 11:06, Peter Gummer wrote: >> Athanasios Anastasiou wrote: >> >>> Is there a known problem with the following archetypes? >>> openEHR-DEMOGRAPHIC-CLUSTER.individual_credentials_iso.v1 >>> openEHR-DEMOGRAPHIC-CLUSTER.person_additional_data_br.v1 >>> openEHR-DEMOGRAPHIC-CLUSTER.person_birth_data.v1 >>> >>> If not, could there be something with the Archetype Editor? It refuses to >>> load these archetypes properly whether it's from the "Open from web" option >>> or by trying to open an ADL downloaded straight from the CKM. >> >> >> Hi Athanasios, >> >> Definitely a known issue ;-) >> >> The Archetype Editor has only ever worked with the openEHR-EHR reference >> model. It was always planned to add support for openEHR-DEMOGRAPHIC, but >> improving the support for openEHR-EHR has always been a bigger priority. >> >> You would be able to load these archetypes in the ADL Workbench, but it >> doesn't have editing capability. ADL Workbench can validate the archetypes, >> however, which is useful if you have edited the ADL in a text editor. >> >> Peter >> >> >> ___ >> 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
Issue (probably known) with ADL Workbench
Hi all, I'm quite new in openEHR, testing last released version of ADL workbench I received an error (ERROR line 87 [last cADL token = V_C_DOMAIN_TYPE]: (VACSIT) cannot add C_DV_QUANTITY object with rm_type_name=DV_QUANTITY to singly-valued attribute value because attribute already has child with same RM type) when I tried to load the openEHR-HER-ITEM_TREE.medication.v1.adl (draft version). I don't know if this is known or unknown but just in case. If I remove from line 73 to line 98 (C_DV_QUANTITY multiple references, just leaving one of them) the archetype is perfectly loaded. The same happened with openEHR-EHR-ITEM_TREE.medication-formulation.v1.adl. In this case the C_DV_QUANTITY values are empty and you need to include values on them. Thanks and regards. Carlos. -- This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informacion confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente pueden estar protegidos por secreto profesional. Si usted recibe este correo electronico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no se hace responsable por su contenido. Su contenido no constituye ningun compromiso para el grupo Atos, salvo ratificacion escrita por ambas partes. Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no sera responsable de cualesquiera danos que puedan resultar de una transmision de virus. --
Possible unknown issue with Archetype Editor
Hello Athanasios, Those archetypes have parts that do not follow openEHR model. All share the same issue, they have a 'constraint reference' inside a defining code attribute. The correct is a 'CODE_PHRASE' class. I think this is a clear example of why we should keep the model outside the parser: This archetype is syntactically valid, but not semantically. Regards 2012/9/13 Athanasios Anastasiou : > Hello everyone > > Is there a known problem with the following archetypes? > openEHR-DEMOGRAPHIC-CLUSTER.individual_credentials_iso.v1 > openEHR-DEMOGRAPHIC-CLUSTER.person_additional_data_br.v1 > openEHR-DEMOGRAPHIC-CLUSTER.person_birth_data.v1 > > If not, could there be something with the Archetype Editor? It refuses to > load these archetypes properly whether it's from the "Open from web" option > or by trying to open an ADL downloaded straight from the CKM. > > Additional information attached. > > Looking forward to hearing from you > Athanasios Anastasiou > > > ARCHETYPE EDITOR: > I wanted to have a look at the Demographic/Address/Address/"Healthcare > provider address" archetype and i chose to do it through the Archetype > Editor (AE) version 2.2.735 beta to be able to save any modifications i > might have wanted to apply. > > Two versions of the AE gave me the same error: 2.2.3[something] and the > latest 2.2.735 beta > > PROBLEM: > *) The AE partially opens a Demographics archetype through the "Open From > Web" option > *) The AE fails to load a Demographics archetype in ADL format coming from a > fresh checkout from the CKM > > REPLICATING THE PROBLEM: > "Open From Web" > 1) File -> Open From Web > 2) Search: Demographics > 3) Select: one of > Cluster/[individual_credentials_iso.v1,person_additional_data_br.v1, > person_birth_data.v1] > 4) OK > > ERRORS: > Incorrect format does not conform to reference model (x7) > INFO - Archetype [archetypeID] Semantics VALIDATED > (ADL_INTERFACE.parse_archetype) > INFO - Archetype [archetypeID] Syntax VALIDATED > (ADL_INTERFACE.parse_archetype) > > "Open from downloaded ADL" > 1) Download "individual_credentials_iso.v1" from CKM > 1) File-> Open > 2) Select: individual_credentials_iso.v1 > 3) OK > > ERRORS: > 1) Error loading: ITEM_STRUCTURE = ADDRESS->ITEM_TREE (x2) > 2) Loads everything EXCEPT the archetype's definition > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
lessons from Intermountain Health, and starting work on openEHR 2.x
Hi, 2012/9/13 Erik Sundvall > It would be great if e.g most of the future ISO 13606 version could be a > true subset of openEHR instead of the current confusing situation. This is something I discussed with Thomas some time ago, it would be one of the best harmonisation solutions, but probably with a slightly different interpretation. Since 13606 has more generic classes (eg. the generic ENTRY can represent all of OBSERVATION, EVALUATION, INSTRUCTION, ACTION), instead of 13606 being a subset of openEHR I think that openEHR should be a specialized model of 13606. Obviously this would require a deep analysis and changes of the models, but that could be the idea. -- 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/pipermail/openehr-technical_lists.openehr.org/attachments/20120913/3286ef2d/attachment.html>
Possible unknown issue with Archetype Editor
Hello Peter and Diego Thank you very much for the quick responses. I did briefly go through the structures to spot the differences and i am really glad to see that someone has already done this :-) Anyway, i thought that it was strange for these to appear on the CKM without loading properly through the AE (otherwise how where they composed?) but after the responses it makes sense. All the best Athanasios Anastasiou On 13/09/2012 11:06, Peter Gummer wrote: > Athanasios Anastasiou wrote: > >> Is there a known problem with the following archetypes? >> openEHR-DEMOGRAPHIC-CLUSTER.individual_credentials_iso.v1 >> openEHR-DEMOGRAPHIC-CLUSTER.person_additional_data_br.v1 >> openEHR-DEMOGRAPHIC-CLUSTER.person_birth_data.v1 >> >> If not, could there be something with the Archetype Editor? It refuses to >> load these archetypes properly whether it's from the "Open from web" option >> or by trying to open an ADL downloaded straight from the CKM. > > > Hi Athanasios, > > Definitely a known issue ;-) > > The Archetype Editor has only ever worked with the openEHR-EHR reference > model. It was always planned to add support for openEHR-DEMOGRAPHIC, but > improving the support for openEHR-EHR has always been a bigger priority. > > You would be able to load these archetypes in the ADL Workbench, but it > doesn't have editing capability. ADL Workbench can validate the archetypes, > however, which is useful if you have edited the ADL in a text editor. > > Peter > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >
Possible unknown issue with Archetype Editor
Hello everyone Is there a known problem with the following archetypes? openEHR-DEMOGRAPHIC-CLUSTER.individual_credentials_iso.v1 openEHR-DEMOGRAPHIC-CLUSTER.person_additional_data_br.v1 openEHR-DEMOGRAPHIC-CLUSTER.person_birth_data.v1 If not, could there be something with the Archetype Editor? It refuses to load these archetypes properly whether it's from the "Open from web" option or by trying to open an ADL downloaded straight from the CKM. Additional information attached. Looking forward to hearing from you Athanasios Anastasiou ARCHETYPE EDITOR: I wanted to have a look at the Demographic/Address/Address/"Healthcare provider address" archetype and i chose to do it through the Archetype Editor (AE) version 2.2.735 beta to be able to save any modifications i might have wanted to apply. Two versions of the AE gave me the same error: 2.2.3[something] and the latest 2.2.735 beta PROBLEM: *) The AE partially opens a Demographics archetype through the "Open From Web" option *) The AE fails to load a Demographics archetype in ADL format coming from a fresh checkout from the CKM REPLICATING THE PROBLEM: "Open From Web" 1) File -> Open From Web 2) Search: Demographics 3) Select: one of Cluster/[individual_credentials_iso.v1,person_additional_data_br.v1, person_birth_data.v1] 4) OK ERRORS: Incorrect format does not conform to reference model (x7) INFO - Archetype [archetypeID] Semantics VALIDATED (ADL_INTERFACE.parse_archetype) INFO - Archetype [archetypeID] Syntax VALIDATED (ADL_INTERFACE.parse_archetype) "Open from downloaded ADL" 1) Download "individual_credentials_iso.v1" from CKM 1) File-> Open 2) Select: individual_credentials_iso.v1 3) OK ERRORS: 1) Error loading: ITEM_STRUCTURE = ADDRESS->ITEM_TREE (x2) 2) Loads everything EXCEPT the archetype's definition
lessons from Intermountain Health, and starting work on openEHR 2.x
Hi! On 12/09/2012 17:43, Heath Frankel wrote: > We need a depreciation scheme that allows us to say that something > is no longer recommended for use in a particular release and removed > in a subsequent release. This gives implementations time to migrate to > the new recommendation. It also means we can get some experience > with what the new recommendation is before we remove the deprecated > approach. Yes, what about using that approach (deprecation scheme etc) for a "stable" or "production grade" series of versions - v 1.0.3, v 1.1 and so on... ...and at the same time start working on an "experimental" 2.x series. This is how it is often done in big open source projects (with a lot bigger user base than openEHR has). Critical systems, in production use, seldom jump over to the new 2.x series while it is young, they wait for it to mature. BUT they have been able to follow and comment on the 2.x development all along the way so that they can be prepared without constraining the options by insisting on full backwards compatibility. The 1.x branch could also slowly make changes to prepare for a simplified future transition to 2.x including adding transformation tools. If we want 13606, CIMI and openEHR modelling to merge somewhere in 2.x, the we can not express too much protectionism from openEHRs side. (I think I have heard people complaining about HL7 protectionism on these lists...) Truly good changes (simplifications, increased archetyping flexibility etc) should not be stopped by protectionism, but of course things should be well tested in implementation before new specifications are finalized. It would be great if e.g most of the future ISO 13606 version could be a true subset of openEHR instead of the current confusing situation. In the openEHR 1.x to 2.x case perhaps we will understand each other better if we discuss concrete examples rather than expressing unspecified fears from both "sides", I'll start one below. Feel free to add other examples (a concrete example of proposed data type changes for example). When you look at http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model, do you then think that the discussed changes at e.g. ENTRY and ITEM_STRUCTURE level will reduce bloat and misunderstandings, at the same time as it increases flexibility and understanding? Would that be truly good for openEHR archetyping and implementation? Ian, an experienced archetype developer, has been asking for this increased flexibility, see: http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model?focusedCommentId=32210974#comment-32210974. (I think Sam also mentioned similar thoughts on the lists earlier.) I had guessed that those proposed changes are big and breaking enough to go for 2.x rather than a "soft deprecation" 1.x series, what is the opinion of those of you that have big systems running? Do they fit in a 1.x series upgrade path? I thought anything that breaks paths would likely be considered a "big" change. (In the example above, the transition path including automated data conversion is pretty clear though.) It is probably better to break these paths in an experimental 2.x series now rather than waiting five+ years and try to squeeze it in to 1.8 or something. :-) > HL7 [...] look what happened when they offered a major upgrade. [...] > The big issue was the effort for vendors to transition existing systems I think that might be a somewhat unfair comparison: 1. The proposed openEHR 2.0 changes I have seen so far are not deviating from the basic design principles and design patterns in openEHR. The basic approach does _NOT_ change the same way as HL7 did between v2 and v3. 2. The number of vendors using openEHR now is _a lot_ smaller than the ones that used HL7 v2 3. The number of vendors we want to join the openEHR approach in the future is _a lot bigger_ than the ones that have existing openEHR-based production systems. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120913/1a6a3d54/attachment.html>
