CKM Release 1.17.0
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 | https://openehr.atlassian.net/browse/SPECRM-89 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 https://openehr.atlassian.net/browse/SPECPR-367 ) 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. Data Types Information Model ). 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 Data Types Information Model 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. |