On 10/01/2012 14:32, David Moner wrote: > Doesn't this create problems while using archetypes/templates as basis > for the generation of data instances? > > I mean, a computed attribute (for example, the EVENT offset) gets its > value from already existing values or attributes of the instance class > (in this example, from the time and the parent.origin). We should not > create the instance if data is not valid regarding the > archetype/template, but we cannot check the validity of the > constrained offset while we don't have the instance complete. It seems > somehow a vicious circle. An assertion here is clearly preferable, > since by definition it is only applied to existing instances. > > David
David, the usual situation in operational systems is that there are RM objects being created by some process. These will not by default obey the template and its archetypes, only the RM; to make the instances obey the template, you have to do something specific, e.g. engineer (or generate) the UI so it only allows exactly what the template says, or... if you have a custom UI (still the case in most real systems today) you will make calls to some programming object to either set or check the data. If you use the 'Template Data Object' approach - an API generated from the template, various types of checking are done. Usually, the checks are done after a 'commit' call is made, and any wrongly set fields have to be fixed by making a new call with appropriate data. This is a similar to the process of the typical web-page on a booking site, where you can't get to the next page until there are no more 'red' fields to correct. There are a lot of different ways to technically do this data setting, too many to explain here, but in essence, a RM-valid but template-invalid RM instance is always possible in the instance building phase; what can't happen in a proper system is for non template-compliant data to be committed to the EHR repository. - thomas
