Hi Øystein,
There seems to be a misunderstanding:
OpenEHR is a specification of a reference model and archetypes, etc, it
is not software, but there is some software to download.
I was trying to be helpful, but it turns out that I was confusing instead.
I am sorry for that.
In the OpenEHR specification, there is versioning specified, this is
versioning of data-entries.
I think now you are referring to that, so I explain that part. If I am
wrong again, please rephrase your question.
Thanks
According tho theOpenEHR specification, entered data are for ever to
keep, they cannot be changed, overwritten or deleted.
They are saved with references to audit-records (describing who entered
the data, when they are entered, why ,etc)
All this is saved for ever.
But in the case when there is an error in entered data, it is possible
to enter changed data .
Those changed data, however, do not overwrite the erroneous data, but
create a new version of the same data-entry.
Together with new audit-data,.
So that both, the data-entry with the error, and the changed data are
saved, but the changed data have the latest version-number, and are the
one the system normally refers to.
How this is happening from technical point of view, is, according to my
last reading of the specs, not specified.
The software-architecture must take care that previous versions,
together with according audit data, can be retrieved.
There are more ways to do this.
I hope I explained it clear
Excuse again for being confusing.
Best regards
Bert Verhees
On 26-10-15 14:28, Øystein Nytrø wrote:
23. okt. 2015 kl. 18.48 skrev Bert Verhees <bert.verh...@rosa.nl>:
On 23-10-15 15:06, Øystein Nytrø wrote:
Would anyone care to comment on how OpenEHR should keep tools, models and
implementations
fresh, sparkling, consistent and usable?
OpenEHR is a specification, although there is some sourcecode, regard that as
an extra service, developed by some contributors, a lot from Ocean Informatics,
but also others.
If you have more specific questions, please ask, the lists are very responsive.
Best regards
Bert Verhees
I regarded OpenEHR as a specification language (environment). Not a
specification by itself?
Ok, I´ll try to be more specific, using Bert Verhees' terminology of OpenEHR as
a specification:
What are the governance processes and procedures related to: versioning,
forking, refactoring etc for:
* "specifications" (- no I do not belive that there will be only one, final,
specification... :-)
* tools used to design and validate the "specification"
* implementations based on a distinct "specification"
And since OpenEHR as "specification" was mentioned, - is it possible to control
consistency
of additions and changes? Maybe inconsistency is impossible.
I may be asking for much, but governance procedures or test/validation
framework seem to be a decisive factor in ensuring a longevity of domain models.
Best regards,
--- Øystein Nytrø
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
