If needed we can create the problem reports a posteriori, just as a log of changes, I mean, each change should have a requirement specified somewhere. Then use semver for the release?
pablo
(Pablo Pazos)
21
Related topics
| Topic | Replies | Views | Activity | |
|---|---|---|---|---|
| Which AOM2 release are AWB/Nedap using for exporting OPT2 to JSON? | 32 | 1177 | 29 November 2021 | |
| Is DV_STATE and it's profile constraint C_DV_STATE used anywhere in the specs? | 22 | 959 | 10 November 2021 | |
| Lifecycle_state in EHRbase | 32 | 2313 | 2 November 2021 | |
| CONTRIBUTION `UPDATE_AUDIT.change_type` in REST API vs vendor implementations | 17 | 122 | 14 June 2026 | |
| Archetype versioning on CKM | 31 | 33 | 16 June 2011 | |
| Looking ahead to openEHRv2 | 27 | 480 | 11 May 2026 | |
| Conflicting specifications in Archie's BuiltinReferenceModels class | 17 | 760 | 27 October 2021 | |
| Is using EVENT in archetypes an inconsistent way of modeling "any event"? | 29 | 1055 | 5 October 2022 | |
| Q on openEHR XML-schema versioning | 14 | 23 | 15 December 2008 | |
| RM Versions | 22 | 12 | 9 February 2009 |