Hi Thomas, Thank you very much for your answers. They were quite clear and easy to understand as they often are. I have some more questions below...
2006/11/7, Thomas Beale <Thomas.Beale at oceaninformatics.biz>: > > > I'll just provide some formal answers below. > > Mattias Forss wrote: > > Hi, > > I'm currently working in a group that has been evaluating archetypes and > they found out that there in archetypes may be needed to add external nodes > from other archetypes instead of only adding complete archetypes as slots. > Does the current ADL specification allow that external parts from other > archetypes can be included? I think the openEHR templates allow to cut off > parts in a slot, but I'm not sure if they can exclude everything except a > single item. > > > - by the use of slots, which you already know about. Use this when > you want to define reusable semantic units (i.e. more archetypes). > Archetypes and slots can be defined at any level - including at low levels. > However, the downside is potentially "too many little archetypes" for > effective management and governance > > Yes, too many small archetypes would probably make the archetypes hard to maintain etc. > - 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? 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... the first "exists" is only needed if the systolic value node is optional; > the above statement in a real archetype would not necessarily be exactly as > above, but the idea is clear. HOWEVER: in clinical terms, this sort of > condition may not be considered as globally applicable as the rest of the > archetype - it might only apply in your hospital. In this case, the same > kind of statement should be added to a template instead. > 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. > Another issue is about computation. For example we could want a > quantifiable magnitude to be the result of two previously entered values. Is > this possible to do in archetypes? Perhaps in the declaration section or the > invariant section? > > this can also be done in the invariant section using a statement of the > form: > > exists(/path1/value) and exists(/path2/value) implies /path3/value = > /path1/value + /path2/value > Though it certainly is useful, this is only to constrain the allowed value and not to compute it. Some business logic in the EHR system would have to use the invariant to compute the allowed value so that the clinician doesn't have to do that (and risk to enter the wrong value and break the data entry process if the value is invalid according to the archetype). I also noticed that archetypes may become ambiguous by using invariants. For example if the cADL says that the value must be > 10 and the invariant says that the value is 5. I guess there is a need for an archetype validator that checks all kinds of things, conformance to RM class names and attributes, existing codes in the ontology section, invariants conforming to cADL, etc, etc. 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. > What if the values should refer to the same thing across different templates, that uses different archetypes? How should the values be linked then, can invariants still solve that? We would also like to ask if there is a way of specifying validity for > questions depending on previously answered questions. E.g. if a certain > answer was given from a multiple alternative question (coded_text), then and > only then, some other group of questions will be valid. Is this possible to > do in archetypes? Perhaps it's possible with invariants? > > same general form as the first one, where the exists() quantifier can be > used with operators like "implies" to state the required conditions. > Does this mean that the invariant allows something like "path/to/coded_text/defining_code = at0003 implies /some/path[atNNNN] occurrences.min = 1" can be used for the group of questions (cluster) we want to be valid? Finally is there a way of specifying the relevance of answers in archetypes. > Say for example that if some laboratory results are too old, could an > archetype contain some restrictions that make it illegal to answer certain > questions because the material that the answers are based upon is too old? > I'm not sure if this is related to DSS or something else. > > this sounds more like an application or DSS area. However, it would not be > impossible to create invariants to do what you want - a typical example > would be for microbiology test samples - the invariant could state that the > sample date/time has to be within X days of $today. We don't quite have all > the variables defined for this yet, but it is not far off. > Okay, it seems to me that many invariants could be added at a local template level to aid basic decision support. This is quite interesting. Regards, Mattias -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061108/5a8df0cf/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
