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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/c474cf97/attachment.html>
