# Some questions **Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154) **Created:** 2006-06-26 13:09 UTC **Views:** 14 **Replies:** 5 **URL:** https://discourse.openehr.org/t/some-questions/12108 --- ## Post #1 by @Mattias_Forss1 Hello again, I have some questions regarding archetypes. First, I wonder if I can start implementing support for Demographic archetypes in the Java archetype editor or if I am dependent of some parts that need to be implemented in the Java reference implementation? Second, I have a tendency to stumble upon new attributes of the different archetypes that are specified in the EHR IM document. There are several attributes there that don't exist in any archetypes yet and I believe some aren't even supposed to be "archetyped" attributes but I haven't found any specification that tells me exactly which attributes should exist in the archetypes. I need to know if _all_ attributes in the EHR IM document can be modeled in archetypes. If not, I think the EHR IM document is more usable to someone implementing a persistence layer than to someone writing the models which are used to create the data to be persisted. As a concrete example to what i mean, I simply cannot find a class name called RELATED_PARTY for an OBSERVATION. Apparently things have changed a lot from some archetypes and maybe this is just obsolete but there are other things as well, for example the OBJECT_REF class that several attributes in the entry package declare but I don't see what they and several other attributes (which to me declare completely unfamiliar class names) use are in archetypes. Please help me understand... Regards, Mattias Forss --- ## Post #2 by @thomas.beale Mattias Forss wrote: > Hello again, > > I have some questions regarding archetypes\. > > First, I wonder if I can start implementing support for Demographic > archetypes in the Java archetype editor or if I am dependent of some > parts that need to be implemented in the Java reference implementation? > > Second, I have a tendency to stumble upon new attributes of the > different archetypes that are specified in the EHR IM document\. There > are several attributes there that don't exist in any archetypes yet > and I believe some aren't even supposed to be "archetyped" attributes > but I haven't found any specification that tells me exactly which > attributes should exist in the archetypes\. I need to know if \_all\_ > attributes in the EHR IM document can be modeled in archetypes\. If > not, I think the EHR IM document is more usable to someone > implementing a persistence layer than to someone writing the models > which are used to create the data to be persisted\. > > As a concrete example to what i mean, I simply cannot find a class > name called RELATED\_PARTY for an OBSERVATION\. this changed in 1\.0 \(probably earlier from memory\) \- see http://svn.openehr.org/specification/TRUNK/publishing/architecture/computable/UML/uml_start_view.html or the current specs\. > Apparently things have changed a lot from some archetypes and maybe > this is just obsolete but there are other things as well, for example > the OBJECT\_REF class that several attributes in the entry package > declare but I don't see what they and several other attributes \(which > to me declare completely unfamiliar class names\) use are in archetypes\. there are quite a lot of attributes \(and even some classes\) in the RM that don't make sense to archetype \- these are attributes whose values can only set at runtime, and there are no sensible deign\-time restrictions\. E\.g\. there is usually no sensible constraint on OBSERVATION\.subject, or workflow\_id\. However, there occasionally is a constraint on subject, and there might even be a constraint on workflow\_id one day\. We used to have an idea of "profiling" the RM to mark attributes that could possibly be archtyed, but I don't think thisis a safe thing to do anymore\.\.\.since there is no guarantee of what might be controlled and what might not be\. Nevertheless, attributes like LOCATABLE\.feeder\_audit probably will nevre be archetyped\. At the moment, we take the approach of only allowing constraints on things for which there have been meaningful examples\. I know thisis not particularly scientific, but I don't think there is a better approach at the moment\. Of course, you can assume at least that only Composition and lower objects can be archetyped \- you can naturally ignore all the change\_control classes, and quite a few others\. We also had a plan to create a subset model of the RM that defines what can be archetyped \- for the purposes of international standardisation\. This could still take place, but getting cooperation from international standards groups is hard\. You are somewhat right that the RM is designed to help design for persistence, but I think it is still close enough to work for archetyping as well\. If you think you can prpose objective rules for profling the RM for archetyping, please let us know\. \- thomas --- ## Post #3 by @Mattias_Forss1 2006/6/27, Thomas Beale <[Thomas.Beale@oceaninformatics.biz](mailto:Thomas.Beale@oceaninformatics.biz)>: > Mattias Forss wrote: > > Hello again, > > > > I have some questions regarding archetypes. > > > > First, I wonder if I can start implementing support for Demographic > > archetypes in the Java archetype editor or if I am dependent of some > > parts that need to be implemented in the Java reference implementation? > > > > Second, I have a tendency to stumble upon new attributes of the > > different archetypes that are specified in the EHR IM document. There > > are several attributes there that don't exist in any archetypes yet > > and I believe some aren't even supposed to be "archetyped" attributes > > but I haven't found any specification that tells me exactly which > > attributes should exist in the archetypes. I need to know if _all_ > > attributes in the EHR IM document can be modeled in archetypes. If > > not, I think the EHR IM document is more usable to someone > > implementing a persistence layer than to someone writing the models > > which are used to create the data to be persisted. > > > > As a concrete example to what i mean, I simply cannot find a class > > name called RELATED_PARTY for an OBSERVATION. > this changed in 1.0 (probably earlier from memory) - see > [http://svn.openehr.org/specification/TRUNK/publishing/architecture/computable/UML/uml_start_view.html](http://svn.openehr.org/specification/TRUNK/publishing/architecture/computable/UML/uml_start_view.html) > or the current specs. > > Apparently things have changed a lot from some archetypes and maybe > > this is just obsolete but there are other things as well, for example > > the OBJECT_REF class that several attributes in the entry package > > declare but I don't see what they and several other attributes (which > > to me declare completely unfamiliar class names) use are in archetypes. > there are quite a lot of attributes (and even some classes) in the RM > that don't make sense to archetype - these are attributes whose values > can only set at runtime, and there are no sensible deign-time > restrictions. E.g. there is usually no sensible constraint on > OBSERVATION.subject , or workflow_id. However, there occasionally is a > constraint on subject, and there might even be a constraint on > workflow_id one day. We used to have an idea of "profiling" the RM to > mark attributes that could possibly be archtyed, but I don't think > thisis a safe thing to do anymore...since there is no guarantee of what > might be controlled and what might not be. Nevertheless, attributes like > LOCATABLE.feeder_audit probably will nevre be archetyped. At the moment, > we take the approach of only allowing constraints on things for which > there have been meaningful examples. I know thisis not particularly > scientific, but I don't think there is a better approach at the moment. > Of course, you can assume at least that only Composition and lower > objects can be archetyped - you can naturally ignore all the > change_control classes, and quite a few others. > > We also had a plan to create a subset model of the RM that defines what > can be archetyped - for the purposes of international standardisation. > This could still take place, but getting cooperation from international > standards groups is hard. > > You are somewhat right that the RM is designed to help design for > persistence, but I think it is still close enough to work for > archetyping as well. If you think you can prpose objective rules for > profling the RM for archetyping, please let us know. Hi Thomas, Our group has just discussed how to profile the RM, and the suggestions we have are simple ones and not too hard to implement. The first suggestion is to keep track of all the archetyped attributes and classes for each release and mark them in the specifications. It can be as simple as just adding an extra asterisk. The idea of doing this at each release also helps the tool developers to find out what has changed since previous versions. Another idea is to make a separate document that lists all the archetyped attributes and classes and this document could be versioned each time some new archetypes are out which uses meaningful examples of previously unarchetyped attributes or classes. A document like this means more work than the previous suggestion but it would also help tool developers to quickly see exactly which version of the document that the tool is most in line with. Hope some of these suggestions appeal to you. Regards, Mattias --- ## Post #4 by @thomas.beale Mattias Forss wrote: > > Hi Thomas, > > Our group has just discussed how to profile the RM, and the > suggestions we have are simple ones and not too hard to implement\. > > The first suggestion is to keep track of all the archetyped attributes > and classes for each release and mark them in the specifications\. It > can be as simple as just adding an extra asterisk\. The idea of doing > this at each release also helps the tool developers to find out what > has changed since previous versions\. we were going to mark the RM like this a couple of years ago\.\.\.\.one of my concerns was that we would have to change the RM docs if we wanted to change the profile of "archetypable" attributes\.\.\.\.on the other hand, a separate document as you suggest below is more work, and harder to keep in sync with the RM\. > > Another idea is to make a separate document that lists all the > archetyped attributes and classes and this document could be versioned > each time some new archetypes are out which uses meaningful examples > of previously unarchetyped attributes or classes\. A document like this > means more work than the previous suggestion but it would also help > tool developers to quickly see exactly which version of the document > that the tool is most in line with\. the main problem remains: what is the definitive list of classes and attributes? We can easily list the packages to include and exclude, but classes and attributes are harder\.\.\.my most recent intention \(no tme to do it yet\) was to express a subset of the RM as a schema that could be read into the ADL tools and used to check anything the user was archetyping\. The problem I guess is that quite a bit of the archetype editor is hard\-wired to the semantics of the model, and this is why you need a definitive list of what to include and what not to include\. I will talk with Sam about this \- he may have some opinions on how we can develop a dependable profle\. \- thomas --- ## Post #5 by @Mattias_Forss1 2006/6/27, Thomas Beale <[Thomas.Beale@oceaninformatics.biz](mailto:Thomas.Beale@oceaninformatics.biz)>: > Mattias Forss wrote: > > > > > > Hi Thomas, > > > > Our group has just discussed how to profile the RM, and the > > suggestions we have are simple ones and not too hard to implement. > > > > The first suggestion is to keep track of all the archetyped attributes > > and classes for each release and mark them in the specifications. It > > can be as simple as just adding an extra asterisk. The idea of doing > > this at each release also helps the tool developers to find out what > > has changed since previous versions. > we were going to mark the RM like this a couple of years ago....one of > my concerns was that we would have to change the RM docs if we wanted to > change the profile of "archetypable" attributes....on the other hand, a > separate document as you suggest below is more work, and harder to keep > in sync with the RM. > > > > Another idea is to make a separate document that lists all the > > archetyped attributes and classes and this document could be versioned > > each time some new archetypes are out which uses meaningful examples > > of previously unarchetyped attributes or classes. A document like this > > means more work than the previous suggestion but it would also help > > tool developers to quickly see exactly which version of the document > > that the tool is most in line with. > the main problem remains: what is the definitive list of classes and > attributes? We can easily list the packages to include and exclude, but > classes and attributes are harder... Do we need _the_ definitive list? I would be content if some tool was developed that ran through validated archetypes and collected class and attribute names and stored them in some hierarchy that then could be generated to documents and/or UML models. > my most recent intention (no tme to > do it yet) was to express a subset of the RM as a schema that could be > read into the ADL tools and used to check anything the user was > archetyping. The problem I guess is that quite a bit of the archetype > editor is hard-wired to the semantics of the model, and this is why you > need a definitive list of what to include and what not to include. I > will talk with Sam about this - he may have some opinions on how we can > develop a dependable profle. Yes, when developing user-interfaces it is hard to make something so general as the RM but also understandable and usable at the same time. Otherwise we'd just loose the point of an archetype editor if it allowed creating whatever the user wanted, for example add an attribute my_attribute with the class MY_COMPLEX_OBJECT as a child. The purpose of an editor would be to create archetypes that are valid to the fullest extent possible and help the user understand the limitations of what can be modeles and what cannot. /Mattias --- ## Post #6 by @thomas.beale Mattias Forss wrote: > > 2006/6/27, Thomas Beale <Thomas\.Beale@oceaninformatics\.biz > <mailto:Thomas.Beale@oceaninformatics.biz>>: > >     Mattias Forss wrote: >     > >     > >     > Hi Thomas, >     > >     > Our group has just discussed how to profile the RM, and the >     > suggestions we have are simple ones and not too hard to implement\. >     > >     > The first suggestion is to keep track of all the archetyped >     attributes >     > and classes for each release and mark them in the specifications\. It >     > can be as simple as just adding an extra asterisk\. The idea of doing >     > this at each release also helps the tool developers to find out >     what >     > has changed since previous versions\. >     we were going to mark the RM like this a couple of years ago\.\.\.\.one of >     my concerns was that we would have to change the RM docs if we >     wanted to >     change the profile of "archetypable" attributes\.\.\.\.on the other >     hand, a >     separate document as you suggest below is more work, and harder to >     keep >     in sync with the RM\. >     > >     > Another idea is to make a separate document that lists all the >     > archetyped attributes and classes and this document could be >     versioned >     > each time some new archetypes are out which uses meaningful examples >     > of previously unarchetyped attributes or classes\. A document >     like this >     > means more work than the previous suggestion but it would also help >     > tool developers to quickly see exactly which version of the document >     > that the tool is most in line with\. >     the main problem remains: what is the definitive list of classes and >     attributes? We can easily list the packages to include and >     exclude, but >     classes and attributes are harder\.\.\. > > Do we need \_the\_ definitive list? I would be content if some tool was > developed that ran through validated archetypes and collected class > and attribute names and stored them in some hierarchy that then could > be generated to documents and/or UML models\. Not a bad idea\.\.\.one of my tools could probably be extended to do that\.\.\.\.\.I'll look into it\. Good thought\. \- thomas --- **Canonical:** https://discourse.openehr.org/t/some-questions/12108 **Original content:** https://discourse.openehr.org/t/some-questions/12108