CKM-1461

Instance-wide Translation Administrators (per Language)

To manage translations, CKM features the project-based role of “translation editor”. A translation editor can manage all translations of archetypes owned by the project.

However, unlike the development and management of the content of archetypes, that is often organised along project boundaries, there is a need for a role to:

• Manage the translations for all archetypes in all projects (as well as incubators) without assigning a project-based role to the user for each project.

• Manage the translations per translation language, not necessarily for all translation languages.

Therefore, this release introduces a new CKM instance-wide role, the role of “Translation Administrator”.

The role Translation Administrator is assigned (by Clinical Knowledge Administrators or Technical Administrators) per translation language, so that a CKA instance can have separate Translation Administrators for - say - Norwegian Bokmål, Catalan, Farsi and German.

The role of Translation Administrators enables the holder of the role to

• Checkout and translate archetypes (relevant if the CKM is configured to restrict resource checkout to user’s with special roles).

• Conduct Translation Reviews (only in the assigned translation language). NB: Reviews are a feature of projects only, not incubators. the user has full access to Translation Reviews of the language.

• Be notified if a new or updated translation (in that language) is submitted by a user to the editors. (Note: In case an archetype owned by a private incubator is translated, the Translation Administrator must be able to view the incubator to be notified)

• Commit an archetype from branch to trunk if the archetype only has changes to translation languages the user is a translation administrator for. (Typically this will be one language, but can be multiple as well). For this to be allowed, there must neither be any other active branches for the archetype, nor must the translation branch to be committed be an outdated branch (i.e. another branch was committed after the translation branch has been checked out. (This is behaviour aligned with the recent restrictions of 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).

• Set the status of an archetype’s translation.

• View the Editors' Task List for the archetypes and make changes to To Dos from the Task List if it explicitly mentions the translation language (either the ISO code or the translation language in server localisation). This is to mark the automatically generated “commit the translation” tasks as completed.

• See the “Editor’s Review Rounds” Dashboard widget and related review round overviews.

• See the Active Branches report.

NB: The above is similar to the behaviour and rights of translation editors of a project, but for all archetypes visible to the user, and only for one (or selected) translation languages.

NB: This role does NOT give the user access to private incubators. If however, the user is a member of a private incubator, the translation administrator can use this role to manage translations of the archetypes in this private incubator as well.

The user interface for CKA or technical admins to grant and revoke user roles (in the User Profile) has been revamped to deal with translation administrators by selecting the appropriate language from a combo box. As part of this rework, the Multiselect boxes with the currently assigned and unassigned user roles) have been removed in favour of combo boxes to grant or remove user roles.

The Translation Administrator role for a specific translation language is created (automatically) on demand only - this is to avoid cluttering systems with hundreds of roles where only a few are currently needed.

Translation Administrators have also been added to the “Users per Role” overview available from the Tools menu for CKAs and technical administrators. A Translation Administrators role is only listed here if at least one user has this role for a particular translation language. This is to avoid cluttering the overview with hundreds of empty roles.

Also see discussion at https://discourse.openehr.org/t/request-to-join-project-as-translation-editor/4170/12 .

CKM-1707

Data Points Report per Project

Add a data point report per project, available directly as a tab from the project.

For normal users, this should be the second last entry, just before the Download of Project Files.

Open

CKM-1807

Support REST-like URLs for direct links to resource centre documents and add the links of these Associated Assets to the Release Set manifests

Direct links to documents are currently only accessible via a query string, e.g.

https://ckm.openehr.org/ckm/document?cid=1013.17.14

https://ckm.openehr.org/ckm/document?cid=1013.17.14&version=1

It should be possible to access the documents via a REST URL, for example:

https://ckm.openehr.org/ckm/documents/1013.17.14

https://ckm.openehr.org/ckm/documents/1013.17.14/1

ckm/documents/<cid-document>

ckm/documents/<cid-document>/<version>

In addition:

• Display this URL in the resource centre instead of the query-based URL.

• Add this URL to any Associated Assets in both the XML based and the markdown based release set manifest.

  • If the associated asset is versioned, use the URL including the version (e.g. https://ckm.openehr.org/ckm/documents/1013.17.14/1)

  • If the associated asset is not versioned, use the URL excluding the version (e.g. https://ckm.openehr.org/ckm/documents/1013.17.14)

CKM-1828

Ability to Add OMOP Mappings to Archetypes and Templates

It is increasingly recognised that openEHR and OMOP can and should be used in combination, cp e.g. https://discourse.openehr.org/t/ohdsi-and-openehr/308/28 . For this to be supported, it is paramount to create detailed mappings from commonly used openEHR archetypes and templates to OMOP CDM where and to the extent possible.

For this purpose, a new Tab has been added for each archetype and template, dubbed “Mappings & Queries” where mappings from openEHR to FHIR can be uploaded and maintained.

There are various approaches to mappings ranging from simple spreadsheets to formally defined YAML files based on the OMOP Conversion Language (OMOCL), a declarative mappings language for mappings between openEHR archetypes and templates to the OMOP CDM.

Since the need is very clear, but the exact formalism is not as of now, CKM at this stage will enable the upload of various file types including YAML and Spreadsheets and remain agnostic to the formalism used.

To display the mappings, some generic syntax highlighting has been added to CKM as well: cp. CKM-2128.

Projects have a new role of Mappings and Queries Editor enabling the management of these artefacts on a project-level. Clinical Knowledge Managers and Project Editors also hold these rights.

With this role, an OMOP mapping file can be uploaded to an archetype or template by providing the file, a title and optionally description, the archetype or template revisions this mapping file applies to, and whether the mapping file is to be versioned. All uploaded mappings files are displayed. If a mapping file is NOT applicable to the currently displayed revision of the archetype or template (typically: the latest or latest published), a warning is displayed for this mapping. Each (text-based) mapping file can be viewed and each mapping file can be downloaded. Mappings and Queries Editors can edit and delete as required.

Note: This work is intended to cater for an immediate need expressed by various parties while some details remain unclear as of now. Depending on uptake this can be extended and finetuned as required in future releases of CKM (e.g. extract meta data from the file if the format and the meta data is agreed upon, provide more detailed governance, provide and overview of all mapping within a project, ability to download of all mappings, …).

Cp. CKM-2104, CKM-2119, CKM-2132 for related functionality.

Example OMOCL mapping file: medical_data/action/Medication_v1.yml

CKM-1926

Complete Rework of the Review Rounds view of each resource

The Review Overview of each resource currently consists of two grids (“Completed Reviews”, “Review Rounds Overview” (collapsed)), and a section to “Open Review Summary”.

This review panel is being revamped as part of this card guided by the idea that review round can be displayed and managed much more intuitively if grouped primarily by Review Round.

Therefore display each review round as one collapsible panel, starting with the newest review round and going down to review round 1.

For each review round, display some core statistics and facts for each review round prominently, such as

• the number of completed reviews,

• the status of the review round (open or closed),

• the initiator of the review round,

• the initiation date,

• the deadline.

In addition, show

• a donut chart of the recommendations of the submitted reviews, and

• a donut chart of the review invitations

for each review round.

Also - depending on the user’s rights - buttons to

• open the review round summary with the consolidated view of all submitted reviews.

• view the review invitations,

• close or reactivate the review round, respectively,

• modify an open review round (opens the known review round panel with the resource already selected), and

• delete an open review round (as CKA).

For user with appropriate rights as CKA or within the resource’s project, an additional grid is displayed to display and manage the individual reviews of the review round.

Open

CKM-1981

Add validation for missing at code on LOCATABLEs

Add a validation check for missing at code on LOCATABLEs - such as ITEM_TREE:

https://discourse.openehr.org/t/missing-at-code-in-item-tree/4035

This should report a VACSI validation error (which seems to be the best match), with a specialised message clarifying that a LOCATABLE mandates an archetype_node_id.

CKM-1985

Clone a Release Set

Ability to duplicate/clone a release set and set back initial state, so that the previous Release Set can be used as a basis for the new release set.

Use Case: A new version for a CDR with an updated set of archetypes and templates. There should be no need to start completely from scratch each time, even with the strict governance mode introduced in CKM-1996 (see below).

In more detail, functionality is introduced to clone a release set from the following places (assuming rights to edit release sets):

• Release Sets/View All Release Sets: click on Release set and select “Clone Release Set”

• Release Sets/Revise Release Set: click on Release set and select “Clone Release Set”

• In the Revision History of a Release Set, click on the Details button of the latest revision and select “Clone Release Set”

Once selected, a prompt appears for the user to provide a new Release Set Identifier (such as myreleaseset.v1).

If the provided release set identifier is valid and not yet in use, the release set is cloned and opened directly to be able to immediately start making changes to it.

Open

CKM-1986

Add a Release Candidate state for Release Sets

Add a Release Candidate state for Release Sets. This is so that release sets can be rejected or accepted in testing stage. If the Usage of the Release Sets fails in the testing environment, then editors would reject the release set and create another RS.

If testing turns out to be ok, editors can then formally publish the release set, otherwise reject it.

It would be helpful to have a “Release Candidate (RC)” state to identify a Release Set that has been integrated in the CDR but is still in the pre-production phase. Once this Release set has been approved for production, the state would be set to “Published”, in the case of being rejected the state would change to “Rejected”.

CKM-1992

Improve the Related Resources Display for "Release Sets Using This Archetype" and "Release Sets Using This Template"

In the Related Resources page of an archetype or template, all release sets that contain the archetype or template (in this exact revision) are listed.

Open

This view should be improved in the following ways:

• Add an icon showing the status of the Release Set in the same way as this is currently already done for archetypes. This refers to the most recent version of the release set using the resource in the currently displayed revision.

• Properly style the “latest revision” etc. indicators as this is currently already done for archetypes.

• Add the Release Set Icon in the header.

• Add right hand top comparison menu button (“Compare/Details) with latest and latest published revision of the release set (as applicable). (Similar for other resource types).

If an archetype or template is contained in various revisions of a Release Set:

• List all release set versions where the archetype or template is being used in.

• Explicitly add the LATEST REVISION or LATEST PUBLISHED indication.

• If the LATEST REVISION or LATEST PUBLISHED is not containing the archetype or template (any more), indicate this as well with a reference to these special revisions.

This results in the following example displays:

Open

Example, if the current revision of the release set does NOT contain this archetype or template anymore in the specified revision:

Open

CKM-1994

Fully enable REST-like Direct Links for Release Sets and use them consistently everywhere for all links

REST-like direct links for release set exist in principle.

They take the form of e.g.

<ckm-server-base-url>/ckm/release-sets/1013.10.30

However, they currently are not displayed like this in e.g.

• emails about a new or updated release set,

• tweets about a new or updated release set, and

• the Release Set Manifest file.

(Up to CKM 1.19.1, the link would have been e.g. #showReleaseSet_1013.10.30)

CKM-1996

Introduce an option for a strict Release Set Governance mode, where Release Sets are locked once in Release Candidate or Published state

This card introduces a new configuration of CKM to support a stricter governance mode for Release Sets.

If this stricter governance mode is enabled in a CKM instance, the following restrictions are enforced:

Once a Release Set has been set to Release Candidate or Published state, (or has been rejected or deprecated), it is no longer possible to make any more changes to the Release Set (i.e. it is not possible to Revise the Release Set). I.e. if a Release Set is in status RELEASE_CANDIDATE, PUBLISHED, REJECTED, or DEPRECATED, the Release Set cannot be revised but is eternally locked.

The states and transitions between states are also reduced, so that it is only possible to transition in the following ways once the Release Set is a Release Candidate or has been published.

• RELEASE_CANDIDATE → PUBLISHED

• RELEASE_CANDIDATE → REJECTED

• PUBLISHED → DEPRECATED

It must not be possible to return to a state that allows modifications to the release set. Thus it is not possible to transition from REJECTED → DRAFT.

The intention of this is that, once a Release Candidate, a Release Set can then either be published (if all subsequent tests with it succeed) or rejected (if any test fails or it needs to be modified in any way for whatever reason), but it can never be modified.

It is however possible to transition from DEPRECATED → PUBLISHED and REJECTED → RELEASE_CANDIDATE. This is to be used only to correct accidental transitions to an inactive state. Note that it is not possible to modify the release set in any of these states in strict governance mode.

CKM-2003

Use "latest revision (unstable)" instead of just "latest revision" to make it clearer that this is not an officially published version

In some places in CKM it is useful to use the wording "latest revision (unstable)" instead of just "latest revision" to make it clearer that this is not an officially published version.

This is most useful for headings and tooltips related to resources that are currently in a REASSESS_* status, waiting to be republished.

(Note: While “latest draft” probably sounds best, we also have the resource states of “DRAFT” and “REASSESS_DRAFT” which would make its use for an overlapping concept somewhat problematic/inconsistent.

Open

CKM-2004

Improve Display of Resource Revisioning in a Release Set's Resources Grids - in particular include the semantic revision number where available

The various resource grids used as part of displaying or creating/modifying a release set should display more information about the revision of the included resource.

This is particular useful for archetypes where the semantic revision number such as 1.10.1 or 1.11-0.alpha can be displayed directly in the revisioning column as well as in the tooltip.

In the revisioning column, use the typical labelbox - also to give another visual indication what is the latest, latest published or a previous revision.

Open

CKM-2006

[Internal] Various Code improvements, refactoring, commenting, cleanup - 1.20.0

Various code improvements, refactoring, commenting & cleanup

• Minor cleanup of ResourcesGridPanels in preparation for Release Set changes.

• Cleanup of ReleaseSetsOverviewPanel before Release Set rework.

• Various Code improvements, refactoring, commenting, cleanup - 1.20.0 Minor clean up of OPTServiceClient and some minor logging improvements.

• Harmonise usage of throwing error if error element from mediaflux in UserHandlerImpl and ProjectHandlerImpl. Minor cleanup of ReviewFunctionalityController and ClassificationHandlerImpl.

• Cleanup in preparation for CKM-1992 - Improve the Related Resources Display for "Release Sets Using This Archetype" and "Release Sets Using This Template"

• Minor clean up of ReleaseSetsOverviewPanel, ReleaseSetHeaderPanel, GridPanelOi in preparation for CKM-2040 Improve Display of Overview of Release Sets and the Display of each Release Set.

• Minor clean up of UserTooltipRenderer and FullTextAsTooltipRenderer in combination with CKM-2040 - Improve Display of Overview of Release Sets and the Display of each Release Set.

• Minor cleanup for ReviewInvitation model in combination with CKM-2040 Improve Display of Overview of Release Sets and the Display of each Release Set.

• Some code and comment cleanup of Object creators, html generators, review field enum and the review feedback history window in preparation for CKM-2046: Error message displayed when Review Feedback History cannot be retrieved (1.19.1)

• Cleanup and improve ArchetypeHTMLPanel in preparation for CKM-2033 On clicking on "Show technical", the panel gets a bit larger and the bottom buttons moved down

• Minor cleanup related to the OPTServiceClient related to CKM-2012 OPT generation fails when an explicit CDATA segment is present (1.19.1).

• Cleanup and finetuning of AssociatedAssetsGridsPanel in relation to CKM-1991 Removing a template from a Release Set may cause the "Recalculating" Wait Dialog to never disappear

• Various rework related to Resource Main Data records and their usage for Release Set modification

• Minor cleanup of code re Rich Text Area and its toolbar

• Clean up service to reactivate a review round in preparation for CKM-2020 - Terminology and Translation Review Rounds should not be able to be reactivated if the main status of the archetype itself is an inactive state (i.e. deprecated or rejected).

• Clean up Statusable, Notifiable interfaces, and some comment finetuning of PResource and subclasses in preparation for CKM-1994: Fully enable Direct Links for Release Sets

• Clean up of DocumentationHandler* classes, AllResourcesPerProjectPanel and services related to transforming operational templates and listing resource documentation in preparation for CKM-2068: Show Project-based OPTs from the Project Resource Centre on the Project Dashboard as well

• Minor clean up of change requests and revision history services

• Minor cleanup of user login and opt classes.

• Minor cleanup of RichTextArea and related classes related to CKM-2062 - Improve Consistency of Formatting when editing in RichTextAreas, especially for the Review Mail Invitation

• Some cleanup of Role Manager and internal user classes in preparation for CKM-1461: Instance-wide Translation Editors

• Some cleanup of various OPT and Value Set Injection classes related to CKM-2087 Transform Changes required to support templates where the same code is used in different 'terminologies'

• Minor cleanup of the Archetype Validation Manager.

• Cleanup/finetune/streamline some backend classes related to CKM-2086 Improve and streamline the query syntax for queries with the main identifier of a resource, CKM-2088 Manually triggered regeneration of OPTs only regenerates 100 OPTs, CKM-2089 Slot fills where no archetype from CKM fits are no longer validated.

• Minor cleanup of ArchetypeSimplifiedHierarchyItem, ArchetypeSerialisedObjectCreator and the Resource Queryer Impl.

• Minor cleanup of UserHandlerImpl in relation to CKM-2086 Improve and streamline the query syntax for queries with the main identifier of a resource.

• Rework ReviewAndReviewRoundDetails to be converted from a Record and use accordingly. Various other finetuning related to CKM-1461: Instance-wide Translation Administrators and CKM-1926: Complete Rework of the Review Rounds view of each resource.

• Clean up of GeneralSpecialQuestionsSpecifyPanel and Clean up of ArchetypeHTMLGeneratorTwoLanguages

• Minor cleanup of Active Branches Report Panel and wordsmithing.

• Cleanup of Resource Documentation related classes/services.

• Minor cleanup of some Change Request and Project related classes/services.

• Clean up ResourceExportPanel (incl. introduction of flex layout) in preparation for CKM-2110 - Resource Mirrored in Git Repository should not be shown for Incubator resources

• Rename title case method for consistency

• Fix potentially/theoretically leaking termset input stream when updating a termset.

• Harmonise colour order in theme.

• Finetune/correct and streamline the css for toolbar, including finetuning of the colour when selected.

• Clean up of General mf Object.

• Clean up Change Request service classes in preparation for: CKM-2134 - Error on Creating a Change Request for a Release Set in any status beyond INITIAL

• Minor Cleanup of Comparison, and Submit Panels related to CKM-2034 - Comparison Report: On upload/commit state the comparison basis: "trunk" or "branch <branchname>".

• Title capitalisation for Order templates in the Project Dashboard and other minor cleanup

• Minor cleanup of mail with recovery sending service and the core String Utils, the frontend String Utils and the logins list service.

• Finetune title capitalisation and general harmonisation of Email headers

• Correct stylesheet errors and ensurer Loading panel is not selectable

• Code improvements and clean up for Template and other Resource related services in preparation for CKM-2141 - OPT generation should honour a language explicitly stated in the oet file over CKM's configured resource display locale

• Code improvements and clean up Resource related services in preparation for CKM-2142 - Prevent reverting a resource if the version is the requested version for reversion is equal to the current version

CKM-2019

Icon Improvements and Additions 1.20.0

• New icon for review invitations used in a variety of places

• Improved icons for the Revision indication in Release sets (latest, latest published, latest and latest published, previous revision)

• New Save icon used for release sets.

• Rework the adoption, watching, not watching, start adopting icons as SVGs

• Rework the Editor's summary of adoptions icon as SVG

• Rework the Resource Centre icon as SVG

• Finetune discussion and classification icons for visibility (especially when selected in the toolbar).

• Rework the Printable View icon as SVG

• Rework the Related Resources icon as SVG

• Rework All Resources and All Order Templates Icons for the left hand explorer.

• Rework as SVG and and improve the various Review type related icons.

• Minor update to the template “org chart” icon

• Rework of translation, translation submit and translation upload icons as SVG

• (Re)move some old icons no longer in use.

• Rework Archetype Proposal Icons as SVGs.

• Rework the three magnifier search/find icons + latest search as SVGs

• Rework Audit Log icon as SVG

• Rework left-hand explorer Expand/Collapse all icons as SVGs

• Rework Projects, Incubators and Projects & Incubators menu / select box icons as SVGs.

• Rework export, import, bulk-export, bulk-import icons as SVGs

• Rework Revise Resource icon as SVG

CKM-2020

Terminology and Translation Review Rounds should not be able to be reactivated if the main status of the archetype itself is an inactive state (i.e. deprecated or rejected)

Terminology and Translation Review Rounds should not be able to be reactivated if the main status of the archetype itself is an inactive state (i.e. deprecated or rejected).

In total, the expected behaviour is the following:

• No resource with an inactive main resource status should have an active review round of ANY kind. In practice this applies to terminology and translation review rounds for archetype. Independent of the status of the terminology or translation, respectively, if the main (content) status of the archetype is inactive, review rounds should not be able to be reactivated.

• Terminology and translation review rounds should also not be able to be reactivated if the status corresponding to the terminology (e.g. Snomed CT) or translation (e.g. Norwegian) is in an inactive state.

• Either way only the latest review round of its kind can be reactivated.

CKM-2022

Review Rounds Overview Panel Finetuning

Various improvements to the review round overview panel available from Reviews/Review round overview with appropriate rights.

1. Change double-click behaviour to open the Review Round Overview (instead of the invitations of the review round which are easily accessible from that panel after CKM-1926: Rework the Review view of each resource.)

2. Adapt the explanatory text accordingly

3. Add an action arrow to the grid for the context menu to be found more easily and also show this on a normal click on the action arrow.

4. Restructure the context menu to use an additional separator. Reorder according to the above and some wordsmithing.

CKM-2029

Localise some components for Norwegian Bokmål and Catalan

Additional localisation of relevant components into Catalan and Norwegian.

Grid menus and Grid groupings for example have not been localised to Norwegian Bokmål and Catalan because this uses a different internationalisation mechanism based on the framework.

Also Framework buttons like Yes, No, OK, Cancel were not translated.

CKM-2030

User Roles Panel: Subdomains and Projects/Incubators should be sorted by name, case-insensitively

In the User Roles Panel available from the User Profile (as a CKA or Technical Admin), the subdomain and then project/incubators should be sorted by their name, case-insensitively. For subdomains, also use the remote or local or customised icon.

CKM-2034

Comparison Report: On upload/commit state the comparison basis: "trunk" or "branch <branchname>"

Resources such as archetypes are compared for example when

• a new revision of a resource is uploaded to a branch, or

• a branch is committed to the trunk.

In the first case, the resource is compared with the latest revision on the branch, whereas in the second case, the final branch revision is compared with the latest trunk revision. This is the case even if the resource was checked out from a previous revision (in which case a warning is displayed and the user must have appropriate full editing rights to continue).

While this is the natural comparison to be executed, for the avoidance of any doubt, the resulting comparison report (“Changes”) should clearly indicate the basis of its comparison such as the branch name or the trunk latest revision.

CKM-2036

Better visual way to close the South Panel Notification

The South Panel with the upgrade notification etc. can be closed by clicking on the tiny arrow in the border between center and south panel.

This is useful, but naturally very easy to miss. Using a right-hand X to close that highlights itself on hover seems appropriate here.

To reopen, the small arrow in the middle can be used, on hover it is also highlighted a bit.

Also, if the notification is a temporary one like an imminent outage to due a CKM upgrade, the right-hand x is of darker colour, whereas for a permanent notification such as a small licencing message, this is lighter.

CKM-2040

Improve Display of Overview of Release Sets and the Display of each Release Set

This issues relates to a series of many improvements to the Display of Release Sets, in particular:

• Improve various height and width and paddings, including the various grids the overview grid, the various grid panels and the header form to make better use of the available space for larger release sets.

• Naming the “Release Set ID” as such (instead of just “release set”)