CKM Release 1.17.0
- Sebastian Garde
Release Notes
Date: October 2021
New & Improved Functionality
Key | Summary | Description |
|---|---|---|
CKM-561 | Ability to attach an archetype to change requests for archetypes and enable editors to import this archetype to a branch | When creating a change request for an archetype, the submitter of the change request should be able to upload an archetype containing the suggested change in addition to describing the change. This way, the submitter can upload the change they suggest directly as part of an archetype. This may be clearer than just a description of the suggested change and may save the editor’s time. This includes functionality to
|
CKM-1257 | Improve the related resource panel of a template to reveal more relevant information on the state of included archetypes | Improve the related resource panel of a template to reveal more relevant information on the state of any archetypes included in the template. Currently the panel lists basic information for each archetype, including the Resource Status of the latest revision of the archetype (which is slightly misleading and may be interpreted as the status of the resource revision used by the template). Therefore, provide the following information for each archetype used by a template:
for each of the following archetype revisions:
For the latest and latest published version, also explicitly display the semantic change type (e. g. patch) from the currently used revision next to the SemVer Revision Number. For example:
This information can directly be derived from looking at the two SemVer Revision Numbers, however, this makes it easier to see. Also, add the ability to compare the archetype revision used by the template with its latest version as well as its latest published version via the Details Toolbar button (as applicable), which has been renamed to “Compare / Details”. 
|
CKM-1265 | For each archetype of a template, add the archetype's semantic version to the Template File Set manifest | For each archetype included in the Template File Set manifest, the semantic version (SemVer) should be stated when available (in addition to the asset version). For example: <revision>0.0.1-alpha</revision> (The manifest is included in the zipped download of each Template File Set.) |
CKM-1413 | Rework Template Upload Error and Warning Display/Grouping | When uploading a new or updated template, the display of errors, warnings and information is somewhat repetitive. Instead of repeating the same error texts over and over again (for larger templates with various problems), group errors and warnings by their type and introduce new headings for each of them. This way the generic explanation text needs to be displayed only once. New Headings for Errors/Warnings include:
|
CKM-1417 | Template Upload Error Display: If no conforming canonical hash exists or no integrity hash is specified in the template, the Semantic Version should be stated as part of the validation | When uploading a new or revised template to CKM as an editor: The template validation error that no conforming canonical hash exists (“Archetype Canonical Hash Mismatch”) should be augmented with the display of the Sematic Version (e. g. 1.0.1), if available. In addition, if no integrity hash is specified in the template at all for an archetype that is used, this “No Integrity Hash” error should also display the Semantic Version for the latest / latest published revision, if available. |
CKM-1422 | Template Upload Previous Revision Warning: Add latest published revision & show the resource status and the semantic change type between the referenced and the latest as well as latest published archetype revision | When uploading a template there may be warning messages that a template is not referencing the latest CKM archetype revisions for one or more archetypes. This “Previous Revision” warning is enhanced in the following ways:
|
CKM-1451 | Increase speed of assembling larger revision histories with many branches | Larger revision histories take a longer time to compile, especially if there are many branches. This issue improves the speed of loading for each revision on the trunk and in each branch by
In total, this nearly halves the time required for backend calculation of typical large revision histories with many branches. (Transfer and actual display in the user’s browser require additional time independent of backend calculation.) |
CKM-1456 | Template Upload Error Display: For Archetype Canonical Hash Mismatch errors display the Hash in the latest as well as the latest published archetype revision | When uploading a template with canonical hash mismatches, we currently only display the Hash of the latest archetype revision. |
CKM-1459 | Publication vs. Development Revision History Views | CKM’s Revision History tab for each resource is currently focussed on providing a development view of its resource, i. e. the revision history displays all revisions - published as well as unstable development revisions - and all branches. This display is very useful when coming from a development perspective and thus must be maintained. The purpose of this issue is to enhance the revision history so that users can switch between
This enhanced revision history only needs to be available for any resource that has already been published at least once. The user is provided with a toolbar button to quickly switch between both views and a message panel clearly indicates the currently displayed view. Users more likely to be interested in the development of the resource are being presented with the Development View. This applies to all members of the resource’s owning project as well as Clinical Knowledge Administrators. Others are presented with the Publication View by default. 
|
CKM-1462 | Change Requests Report: For projects, optionally include Change Requests for resources referenced by the selected project as well | In the Change Request Report it should be possible to also display the Change Requests for resources referenced by a selected project (or a subdomain) in addition to Change Requests for resources owned by a selected project (or by any project within a subdomain, if a subdomain is selected). For this purpose, add a checkbox to “include referenced resources” to the Change Requests report. In the general Change Requests report (available from the Reports menu), this checkbox is only active if either a project or a subdomain has been selected. In the Change Request report tab of each Project, the option is always enabled. |
CKM-1464 | Add number of Priority Change Requests to the Change Request Report | In the Change Requests Reports, the number of Priority Change Requests should be added to the report as well. For each row (as requested) of
CRs, the number of priority Change Requests is added afterwards in brackets. This is so that it is more easily possible to identify all resources with Priority Change Requests. |
CKM-1473 | When internalising an archetype, add an additional line break after the "Derived from" part in the references | When an archetype that is currently referenced from remote via a remote subdomain and the archetype is internalised, the editor can add a “Derived from” note with a link to the original archetype. This “Derived from” statement is added to the top of the References in the archetype. Currently, this is separated by a line break from any pre-existing references. This change adds an additional line break between the two parts so that one empty line is displayed in between. When such an archetype is converted to ADL2, the archetype lists all references separately (ignoring any empty lines). |
CKM-1474 | When manually changing to a 'Team review' status, add a warning message that this is usually an automated changed upon initiating a review round | For the benefit of some (edge) use cases, it is possible to directly (manually) change the status of a resource to "Team review" or "Reassess (team review)". However, doing so manually is usually neither necessary nor desirable. Therefore, add a warning message when manually updating to a Team review state that this is usually done automatically on initiating a review round and thus likely unnecessary. |
CKM-1476 | Translation Editors should get an earlier error message if trying to commit a branch to the trunk that does not only contain translation changes | A translation editor can commit branches to the trunk only if the branch contains translation changes only. Currently, the editor can always start the commit process and only at the end when pressing the commit button, it is checked that the branch cannot be committed by a translation editor. This issue improves this behaviour in the following ways:
(Includes some display finetuning, mainly widths and paddings) |
CKM-1477 | Translation editors should only be able to commit translation-only branches if there are no other active branches for that archetype and if the branch is not outdated | Translation editors should only be able to commit translation-only branches if
As before, translation editors cannot commit an archetype if the archetype contains any content changes (not only translation updates). |
CKM-1478 | Instance-wide configurable ability to prevent editors from assigning other editors and translation/terminology editors to a project/incubator | For some CKM instances, it is important that project/incubator editors can assign the role of editor, translation editor or terminology editor to other users (this is the way it has been up to now). However, for other CKM instances with a stricter governance model implemented, it is important that this is not possible. Therefore, a new instance-wide configuration option is being introduced that controls whether editors of a project/incubator can or cannot delegate editorship rights for the project/incubator to other users. In detail:
Customers that would like to configure this to NOT delegate editorship rights, please contact Ocean. |
CKM-1482 | Ability to a) view a translation in the translation tree and b) start editing the translation from the translation "donuts" on the Resource Status Tab | Ability to
directly from the translation donuts on the Resource Status Tab of each archetype. |
CKM-1483 | Change code for episodic composition from 435 to 451 following erratum issued for RM 1.1.0 | SPECRM-89: Add 'episodic' type to COMPOSITION.category Closed introduced the episodic composition category by assigning code 435 to it. However, unfortunately, it appears that this code is used in some systems to mean laboratory instead (see SPECPR-367: Code for 'episodic' clashes with 'laboratory' in openEHR terminologyClosed ) Therefore, an erratum was issued for RM 1.1.0 and the openEHR RM spec was updated. The new code assigned for episodic compositions is 451. This code (451) is now used by CKM as well. |
CKM-1485 | Add additional meta data for archetypes to the REST webservice to improve external revisioning | Add the following additional meta data to REST API calls for archetypes:
|
CKM-1492 | Upgrade to latest Archie version for ADL2 conversion (1.0.2) | Upgrade to latest Archie version for ADL2 conversion. Most notably, this includes conversion fixes
|
CKM-1494 | Improve resource revisioning and status indication in the resource main heading, the drop down to switch between latest and latest published revision, the archetype references display, the Resource Tab Tooltip, and the left-hand explorer tooltip | Improve resource revisioning and status indication in the resource main heading (where the resource's main display name is displayed together with the status icon, remote icon, and branching and revisioning information), the drop down to switch between latest and latest published revision, the archetype references display, the Resource Tab Tooltip, and the left-hand explorer tooltip. In detail:
|
CKM-1495 | Warn the user before closing a tab with an actively edited translation tree | Currently, it is possible to just close the tab if a translator has made changes to the translation of an archetype using CKM's translation facility. |
CKM-1505 | Collapse Closed Change Requests by default | The Closed Changed Requests subpanel for a resource should be collapsed by default unless a closed change request has explicitly been requested to be shown. This is consistent with behaviour for tasks on the To-Do List. This is especially useful when accessed from the information/warning that there are open change requests - as displayed during revisioning activities such as committing or publishing a resource. |
CKM-1510 | Preview archetype mind map for archetype proposals and change requests | If an archetype has been attached to an archetype proposal or change request, add the ability to preview its archetype mind map directly from the proposal or change request. This is to support editors by visualising the overall structure of the archetype in a better way than this is possible via the already available Tabbed Preview of the archetype. |
CKM-1512 | The Semantic Revision of an archetype should be shown for currently or previously published archetypes even if they are opened from the Find resources tab | CKM-1459: Publication vs. Development Revision History Views improved the Resource Revisioning and Status Indication in the Resource Main Heading, the drop down to switch between latest and latest published revision, archetype references display, the Resource Tab Tooltip, and the left-hand explorer tooltip. For consistency, this issue extends CKM-1459 in the following way: |
CKM-1517 | Various minor display improvements | Various minor display improvements, including the following:
|
CKM-1519 | Ability to export various grid data as CSV for further analysis and reporting for example in Excel | For some of the grid panels (tables) used in CKM, it is sometimes useful to be able to export the data for further analysis and reporting. |
CKM-1520 | Ability to export the core data of various charts as CSV for further analysis and reporting for example in Excel | For some of the presented charts, it is sometimes useful to export the chart’s core data for further analysis and reporting. |
CKM-1524 | When inside a discussion thread, the "Show All Topics" button should be moved further down to the left of the Reply button | It is essential functionality to go back to all discussions when looking at one particular discussion thread. The existing “Show All Topics” button does exactly this, but is placed next to the search box and is thus easy to miss. Therefore: Move the button further down and to the left of the (upmost) Reply button. Includes some minor display tweaking. |
CKM-1526 | Editor should be warned before deleting a task from a resource's to-do list | Currently, when a user clicks on the button to delete a task from a resource’s to-do list, the task is deleted immediately. |
CKM-1527 | Upgrade LOINC to Version 2.71 • Released 2021-08-23 | LOINC as the international standard for identifying health measurements, observations, and documents, is internally used by CKM to resolves LOINC term bindings in archetypes. This issue upgrades the LOINC version used by CKM to version 2.71 (released 2021-08-23). |
CKM-1528 | Ability to export the Publication Report as CSV | In addition to typical grid panels (CKM-1519) and various charts (CKM-1520), the Publication Report available from the Reports menu, should also be made available as a CSV file. |
CKM-1531 | Display a pre-constrained magnitude status (e. g. ~ for approximate) for DV_QUANTIFIED datatype subclasses | Display a pre-constrained magnitude status for datatypes subclassed from DV_QUANTIFIED (cp. https://specifications.openehr.org/releases/RM/latest/data_types.html#_quantity_package ). In some cases, it may be desirable to constrain the magnitude_status in the archetype (rather than just setting it in runtime data). Data types Spec DV_QUANTIFIED itself introduces the concepts of magnitude and magnitude_status. The magnitude attribute is guaranteed to be available on any DV_QUANTIFIED, carrying the effective value, regardless of the particular subtype. The optional magnitude_status attribute can be used to provide a nonquantified indication of accuracy, and takes the following values:
If not present, meaning is "=". Cp. magnitude_status https://specifications.openehr.org/releases/RM/Release-1.0.3/data_types.html and the discourse discussion at: Approximate dates In cases, where the magnitude_status is explicitly constrained in an archetype, e. g. ELEMENT[at0003] occurrences matches {0..1} matches { -- DV_DATE_TIMEtest
value matches {
DV_DATE_TIME matches {
value matches {yyyy-mm-ddTHH:MM:SS}
magnitude_status matches {"~"}
}
}
}the magnitude_status should then be displayed in CKM as well. Note that in cases where the magnitude_status is not constrained, data instances can use any magnitude_status, defaulting to the exact (point) value. NB: The fact that CKM now displays the magnitude_status when it is constrained in an archetype, does not imply that this is an attribute that is considered to be commonly constrained in an archetype. In most cases, the correct magnitude_status is just set on runtime if it is different to the default “=” exact value, for example if all that is available is an approximate (~) date of birth. |
CKM-1543 | Add additional image to the CKM Dashboard's "Become a Part of our Online Community" Widget | Add additional image to the CKM Dashboard's "Become a Part of our Online Community" Widget in addition to the current four images - with one randomly chosen on loading CKM. (This widget is only displayed on the dashboard when the user is not logged in.) |
CKM-1546 | Implicitly used parent archetypes should be included in Template File Sets | If a specialised archetype is used in a template, but its parent is not directly used in the template as well (at a different location), the parent archetype is NOT needed for constructing the Operational Template. The specialised archetype is (in its 1.4 flat form) already includes all the relevant information for this. However, for modelling tools, the parent archetype may still be valuable to have, for example to construct diffs and adl2 source format. There, as a best effort, CKM now provides the revision of the parent archetype that was available in CKM at the time of uploading the revision of the specialised archetype used by the exported template. If no parent archetype existed in CKM at that point in time, its first revision is provided. To clarify this behaviour CKM adds the following note to the template file set's readme file in such cases.
|
CKM-1548 | Enable support for a special logo that can be used in the configurable email prefix if neither the configured customer's header logo nor the configured big version of the logo in the CKM's AboutPanel are suitable for this purpose | Enable support for a special logo that can be used in the configurable email prefix if neither the configured customer's header logo nor the configured big version of the logo in the CKM's AboutPanel are suitable (e.g. transparent, email client dark mode, ...) Compare with Release Notes from 1.16.0:
Customers that would like to configure these styles, please contact Ocean to discuss the configuration details. |
CKM-1568 | When opening a user for viewing via the context menu of a user grid in a window, the user profile should be displayed in a window on top of it rather than a CKM tab half-hidden underneath | When opening a user for viewing via the context menu of a user grid in a window, the user profile should be displayed in a window on top of it rather than a ckm tab half-hidden underneath. For example:
-> The User Profile and the user's "Domain, Profession & Language" should be displayed in a Window on top of the current window. It should no longer open a CKM tab in the background which depending on screen real estate may not or barely be noticeable. |
37 issues
Bug Fixes
Key | Summary | Description |
|---|---|---|
CKM-448 | Improved error message when trying to use a direct link where a discussion topic has been deleted in the meantime | CKM should provide a better error message when trying to open a direct link to a discussion topic when that discussion topic has been deleted. One example is when the direct link to the discussion topic has been posted on e. g. Twitter or sent via email or posted on some website and the (complete) discussion topic has been deleted afterwards in CKM. In this case, an error should be shown: “The requested discussion topic could not be found. It may have been deleted in the meantime.” Also, all available discussion topic for the resource should then be displayed. |
CKM-1452 | Increase the width of the select box to set a new Resource Status so that "Reassess (Review suspended)" does fully fit | On the Resource Status page for a resource (archetype, template), an editor can select a new status for the resource (e. g. Team Review or Published). For Reassess (Review suspended) the expanded list width is insufficient so that it is cut off. Therefore: Increase the width of the select box to properly fit Reassess (Review Suspended) as well as its translations (in German it is currently longest) |
CKM-1453 | Missing and outdated icons during Release Set creation process | When creating a new Release Set, the following icons were missing or outdated
|
CKM-1454 | If an archetype is not (no longer) parsable, the Validation Report for a group of archetypes should not fail to continue the validation and thus display | For an archetype that exists in CKM but is not or no longer parsable (for whatever reason), requesting the Validation Report for a group of archetypes via the Tools menu or via the corresponding project's page should not completely stop the validation with an error. Because non-parsable archetypes cannot be imported into CKM in the first place, this is only relevant for archetypes that were uploaded using a more lenient previous parser, for example one that allowed “NO” as language. |
CKM-1460 | Dictionaries for cached terms from a terminology cannot be accessed after upgrade to latest database version | After upgrade to the latest database version, the dictionaries used to store cached terms from external terminologies cannot be accessed due to (changes in plugin service permission handling). Anytime when users want to display an archetype that has terminology bindings (to e. g. LOINC), an error message is displayed that the dictionary does not exist. NB: This issue is a consequence of upgrading to the latest database version and has never been an issue in a production system. |
CKM-1463 | A project's or subdomain's change request tab shows too many change requests once options are changed | On a project's or subdomain's Change Request Report tab shows unrelated Change Requests if options are changed. For example:
-> Change Request for Resources that are not related to the current project are erroneously shown. |
CKM-1465 | Improve/correct VDFAI validation | The VDFAI implementation seems to be not 100% correct in the Java Reference Implementation. VDFAI Archetype identifier validity in definition. Any archetype identifier mentioned in an archetype slot in the definition section must conform to the published openEHR specification for archetype identifiers
Requires changes to the VDFAI validation check following the discussion at https://discourse.openehr.org/t/vdfai-validation-interpretation/1433 and integrating this into CKM. |
CKM-1466 | Listing active branches can sometimes be very slow with the originally targeted database version for CKM 1.17.0 (and sometimes is very fast) | Listing Active Branches can sometimes (not always) be very slow. This manifests itself in several places, including:
Note: This is a problem that was never in a production system - although the change now implemented will likely increase the speed further. |
CKM-1470 | The "Import from Remote" functionality may miss that some newer archetypes have been updated remotely | CKM's "Import from Remote" functionality available to CKAs from the Archetypes menu, may miss some newer archetypes that have previously been imported and which can now be updated to a newer revision. This happens only when a large number of archetypes have previously been imported from remote. |
CKM-1471 | Import from Remote: When updating to newer revisions of - now - rejected or deprecated archetypes, all revisions are listed | Importing Archetypes from Remote: For example, if a local CKM currently used revision 8 of a remote archetype and this archetype is now in revision 10 and set to Rejected, CKM should only list revision 9 and revision 10, but not any previous revisions. Also fix trivial display oddity for the link to the archetype (space before the link icon looks underlined due to link) |
CKM-1472 | Interval of Duration Icon is rendering wrongly | The Interval of Duration datatype icon is corrupted in that it specifies a wrong size. |
CKM-1479 | A Translation Editor can see the Revise/Commit... archetype menu, but then cannot select any archetype | A (Project) Translation Editor sees the Revise/Commit... archetype menu, but then cannot select an archetype. When a translation editor uses the functionality, the tab opens, but for any archetype the translation editor is given a “You do not have the rights to commit” error message - even if the user is translation editor of the project of this archetype. See CKM-1477: “Translation editors should only be able to commit translation-only branches if there are no other active branches for that archetype and if the branch is not outdated” for more details on when a translation editor should be able to commit a branch archetype to the trunk. |
CKM-1480 | A Translation Editor should not be able to update the content contributors on the branch, because then the translation branch cannot be committed by the Translation Editor anymore | Currently, a translation editor can update the content contributors on a branch, but then is not able to commit the branch anymore without the help from an editor or Clinical Knowledge Administrator (CKA), even if it contains only translation changes otherwise. A translation editor should not have the functionality to update contributors (via the context menu of the branched archetype). Note that this is not functionality required for managing translations because the contributors here refer to the content of the archetype, not the translations. Meta data about the translations is kept separately and can be managed by the translation editor. |
CKM-1484 | Correctly parse DV_DURATION interval constraints where lower and upper is specified and > and/or < is used to indicate that lower or upper are non-inclusive | An archetype with a DV_DURATION interval constraint like
causes a parsing error due to the “<“ in it. While this is logically equivalent to
it should still be supported as well. Example ADL extract: ELEMENT[at0018] occurrences matches {0..1} matches {
value matches {
DV_DURATION matches {
value matches {PD/|P1D..<P1000D|}
}
DV_INTERVAL<DV_DURATION> matches {
lower matches {
DV_DURATION matches {
value matches {PD/|P1D..<P1000D|}
}
}
upper matches {
DV_DURATION matches {
value matches {PD/|P1D..<P1000D|}
}
}
}
}
} |
CKM-1486 | Correct produced media type to text/plain for retrieving the md5 hash via the REST API | Correct the produced media type to text/plain for retrieving the md5 hash via the REST API. |
CKM-1488 | Year 1970 modification time (mtime) retrieved for assets in a certain range of creation when retrieving via xpath query | A defect of the underlying database system caused modification times not to be retrieved correctly for a certain range of assets created from 2015-08-15 to 2018-01-08 on the openEHR CKM instance. This only happens under very specific query retrieval conditions (when the modification time is explicitly requested, rather than retrieved as part of the asset as a whole. The one place where this has a visible effect in CKM 1.16.x is on the timeline displayed on the status page for a resource. If the resource was created (not: last modified) during the above time period, the date of the “Latest revision” is shown as 01-Jan-1970 in the timeline. |
CKM-1489 | For users with a large number of project roles: Increase speed of various calls such as retrieving the revision history of archetypes | CKM users with a large number of different project roles experience performance issues for some calls. Previously, a user with many project roles (e. g. editor for 30 projects and reviewer for another 10 projects) would have seen a huge loading time difference between being logged in and logged out when opening the revision history. While this is ultimately related to an inefficiency of the underlying database system, it was possible to restructure the role handling in CKM to mitigate the effect of this inefficiency, so that the performance has been improved considerably for such users. |
CKM-1491 | Revision History Panel may display a "latest published" label for a wrong revision if there are specific translation status changes afterwards | Revision History Panel may display "latest published" for a wrong revision if specific status changes were made afterwards. For example:
In this case, the correct LATEST PUBLISHED version is 5 (and not 3 as displayed erroneously by CKM 1.16.x). (Only in version 6, the archetype content is not immediately republished, and thus the state is changed to REASSESS_DRAFT.) |
CKM-1497 | UCUM validation leads to a false positive error for units with annotations that contain a . or an / | UCUM validation leads to a false positive error for units with annotations that contain a “.” or an “/” According to the grammar the annotations can contain any 7bit ASCII-char which includes “.” and “/” One example in practical use is See common code 437: milligram per day per 1.73 square meter in UCUM TableOfExampleUcumCodesForElectronicMessaging The above example is correct, however CKM 1.16.x claims this to be incorrect. |
CKM-1498 | Role of a user within a project may still be displayed as "null null" if the user has been deleted without revoking the role first | A role of a user within a project may still be displayed as "null null" in the project members grid if the user has been deleted without revoking the role first. Therefore:
|
CKM-1499 | Template Hierarchy Display: Tooltips on archetypes that are used by the template in a previous/outdated revision show a trailing "]" after the archetype id | In the Template Hierarchy Display (Org Chart like diagram) of a template: |
CKM-1500 | When switching between revisions of a resource and opening the initially used version a second time may lead to some display problems | When switching between revisions of a resource and opening the initially used version a second time may lead to some display problems such as that the mind map or the simple view of the resource is not properly displayed or switches to the wrong tab instead of opening the correct revision of the resource. One way to reproduce this behaviour is to follow the following steps:
→ This activates the first archetype tab again (with the latest revision), instead of opening the correct (outdated) revision used by the template. This may also cause one of the archetype mind maps to layout incorrectly (everything more or less on top of each other). Another way:
|