On 11/13/06, Mattias Forss <mattias.forss at gmail.com> wrote: > > Hi Thomas, > > 2006/11/12, Thomas Beale <Thomas.Beale at oceaninformatics.biz>: > > > > Mattias Forss wrote: > > > > > > > > > * in some cases, most likely what is really needed is to be > > > able to reduce the work required to build archetypes in the > > > authoring tool environment - in other words cut and paste, > > > or smarter things than that. So - what is smarter than cut > > > and paste? We can consider that there are "archetype > > > fragments" which are stored and indexed in a sophisticated > > > authoring environment. These would not be separate > > > archetypes as such - just pieces of archetypes that have > > > been identified as re-usable in the authoring environment, > > > but otherwise not sensible self-standing semantic units. > > > Think about it this way - in some cases, you are not after > > > another archetype, you just want to make sure that you build > > > > > the little piece of the current archetype inn the same way > > > as you did last time, without missing a term. > > > > > > > > > Agree, but shouldn't there be some way to link the "copies" with each > > > other, because they _will not_ be the same data if they don't have the > > > same archetype path? How should we know if we already entered similar > > > values in another archetype, possibly even found in another template > > > than the current one? There should be some way of linking values > > > together. Can it be done at the template level or must it be done at > > > an even higher level, i.e. in business logic of the GUI in the EHR > > system? > > not sure what you mean here. If I make a copy of a piece of an archetype > > that is in some "archetype fragment library" into archetype A and > > archetype B, these two archetypes will have the correct archetype paths > > according to where the fragment was put. When you say "data" and > > "values" are you talking about when the archetypes are used at runtime > > to create EHR data? > > > Archetype A and archetype B will have 'correct archetype paths according > to where the fragment was put', but will they refer to the same paths? When > I talked about data I meant what was stored in the EHR system and when I > talked about values I meant what was entered in the template. > > I tried to ask if there is some way to make two or more archetypes > manipulate exactly the same data in an EHR system, meaning that the > archetypes probably must refer to the same paths - otherwise the data will > be manipulated at different places and the system must know that the data at > the different places are actually the same. Consider this example: > > Archetype A is used in a template to create data about a patient's weight > and archetype B is used in another template and will also create data about > the weight. However, if the weight data was already entered in the EHR > system, is there a way (to create archetypes) which make the system know > that it deals with the same data no matter if it came from archetype A or > archetype B and fetch the last entered value to any of the templates that > need the weight information? >
I am not sure if it's safe to allow cross-use of internal archetype nodes for data entering. A better approach in my view is to separate the common archetype node into a standalone archetype and include it in other archetype or template. For read-only purpose, DV_EHR_URI is perhaps a solution. Cheers, Rong > > > > I will probably make it possible in the Java archetype editor to copy > > > definition nodes between different instances of the program, but that > > > is just a start. The ideal would be to support imports of nodes found > > > in the definition of several selected archetypes... > > it might - but I wouldn't rush with too much new functionality. There > > are other priorities in my opinion, such as: > > > > * getting a testing programme going, and getting user feedback > > * connecting the editor to openEHR and other terminologies (such as > > an instance of the Ocean Terminology Server, designed specifically > > > > for archetype linking to Snomed and other terminologies) > > > Yes, of course there are more important things like these to prioritise > first. > > > Yes, this condition would of course only be added in the template > > > since it is not a global requirement (however there may be such also), > > > but the invariants seem to have a lot of potential and would > > > significantly aid decision support. > > they will, but they are harder to process - we need to get more people > > using the tools for now with the basic functionality, and invariants > > developing more slowly as the user community starts to understand what > > it really wants to do with them. > > > Agree. I also must point out that I meant data entry support above, and > not decision support. > > >> Another feature is value reporting, which should work when we use > > >> several archetypes in an openEHR template. For example if some > > >> question was answered in one archetype, then another archetype that > > >> has the same question should get the value reported from the previous > > >> archetype. Is this possible? I guess this has to do with external > > >> references as I mentioned in my first question. > > > > > > you normally would not allow this in the template if the values > > > were meant to refer to the same thing (i.e. only entered once by > > > the user); if this is not the case, you could add an invariant to > > > the template. > > > I meant if we use two different templates, i.e. values are not entered in > the same template. Please see the weight example above. > > Regards, > > Mattias > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061113/ea740c60/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
