I don't think so, but maybe we could use the release_candidate state, instead the draft one that I mentioned.
2014-11-13 19:32 GMT+01:00 Diego Bosc? <yampeku at gmail.com>: > 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/c29ab281/attachment.html>
