Could "autogenerated" be a valid lifecycle state?
2014-11-13 19:23 GMT+01:00 Thomas Beale <thomas.beale at oceaninformatics.com>:
> On 13/11/2014 16:50, David Moner wrote:
>
> As you say, this information should be somehow related to the "is_generated"
> flag. But if we consider that once a human user reviews the archetype that
> flag is set to false, then I don't find it needed at all.
>
>
> ah - but consider the situation in which the generation step is done
> multiple times, over a period of time. I was in this situation with my
> internal 1.4 => 1.5 (now => 2.0) generator, where it took some time to get
> the converter right. And Patrick Langford is iteratively getting the
> Intermountain converter right over a period of some months.
>
> The ADL WB always looks at that flag to know what to do. If you right click
> on an archetype in the left side explorer, and do 'Edit', the GUI editor
> (alpha for the moment, but functionally the same concept as the LinkEHR
> editor) starts. If the user actually makes any changes and commits them, the
> AWB removes the is_generated flag. Then a later round of import generation
> can look at it, and not overwrite this particular archetype, and instead
> generate a warning (or it could try to do a merge, or..). So I think it's
> needed.
>
> What we would need instead is to define a good practice that says that when
> an archetype is built automatically it must be in draft state, pending of
> further validation, as any other draft.
>
>
> well that depends on whether we think an import step always creates a
> 'draft' archetype. It might be that the source model, say an Intermountain
> CEM is actually in an 'approved' state, and Intermountain (and maybe even
> CIMI) don't intend to do anything furhter with it after import. Although not
> likely to be the most common case, I don't think we can presuppose that the
> lifecycle is rigidly restarted because of an import step.
>
>
> In any case, adding the information that you propose about the original
> source or the import method seems very useful. I have the doubt if a new
> metadata section is needed or it could be considered as reference
> information or just as other details. A new section makes it more traceable
> automatically, as you say.
>
>
> I'm not too worried either way, but more inclined to add new meta-data
> sections if we think we know what they look like, since it reduces interop
> errors - there's no choice about the property names etc, wheres it's always
> a risk to hope that everyone will get the other_details section tags
> identical.
>
> - thomas
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
