...
Date | Attendees | Agenda | Background | Responsible | Notes, decisions and action items |
---|---|---|---|---|---|
| |||||
| Silje Ljosland Bakke | Process for approval and publication of modelling patterns | What should be the process for approving and publishing modelling patterns? For the proposed ENTRY-linked gradings and classifications pattern, there is an outstanding discussion about assertion dates. This discussion is probably on a too detailed level for the CKA coordination group, but what’s the best level for having this discussion? Could this be an initial task for an “Editorial/modelling coordination group”, preparing items like this for the CCG? | We've proposed a modelling/editorial coordination group to be established, which can prepare such cases for the CKA coordination group. The process may work as follows:
Suggestion to make "demo" archetypes for each adopted pattern. These would need to be a bit hidden, so as not to risk people using them in implementations. In a incubator, or so? Conclusion: Bring this topic up in the CPB meeting on the 16th. | |
Organisation of international reviews and publication | How is the international editorial, ie reviewing and publication, work being done at this time, and how can this work be sped up while keeping the integrity of the CKM? As an example, how can we scale the pre-review process of proposed archetypes to be edited/reviewed by a specific initiative or project? | While the editorial work is more easy to distribute, the "pre-evaluating" process would be much harder, as it’s required to avoid overlapping and/or conflicting archetypes. Suggestion to create a detailed checklist for evaluating proposed archetypes, so that the initial evaluation can be done by one person. Any discrepancies can then be turned into Jira tasks for the proposer to resolve before a CKA will import the archetype. Suggestion to embed a simplified checklist within the CKM the user has to evaluate before propose the archetype? A) checked conflicting archetypes, b) checked the style guide, c) something something. This will reduce the workload on the CKAs or editor group. The whole process could be tracked in Jira for transparency and ability to see where the archetype is in the process. Another check before sending on review? Not necessary? All this requires funding and resourcing! Conclusion: Bring the topic, and particularly the funding requirement, up with the CPB on the 16th. | |||
| Silje Ljosland Bakke | Welcome and presentation round | |||
Goals and expectations for the group |
|
| |||
Overview of ongoing international editorial projects |
Document here: International archetype editorial collaborations | International archetype editorial collaborations - openEHR Clinical - Confluence (atlassian.net)
| |||
Backlog of change requests and proposals | How to fund and progress? | There is a backlog of change requests and archetype proposals. The work needs to be funded. The CKAs at the moment are not funded. In the last CPB meeting it was discussed to create a working group to address this. Need to identify requirements, amount, cost etc. | |||
New change requests and proposals | What’s the best forum to progress these? May need attention at both CKA and editor level. | eeds a continous prosess. CKAs are appointed to protect the content of the CKM. The decisionmakers will have to be the international CKAs. Working with change requests and proposals is detailed work. Perhaps too detailed for this group. | |||
Modelling pattern for ENTRY-linked classifications and gradings | For example TNM, Gleason, Gustilo-Anderson, which are always linked to a diagnosis, pathology result, physical examination result, or imaging result: ENTRY-linked gradings and classifications | There has been created a suggestion for how to document modelling patterns: Modelling patterns - openEHR Clinical - Confluence (atlassian.net) Discussion about suggestion for documentation of modelling patterns:
| |||
Updating existing Specialisations when parent archetype has been up-versioned. | Example: CLUSTER.exam that is now .v2 and specialisations are .v1 | Should this be managed in this group? The reason that the specializations are not progressed is because of lack of funding. The upversioning is now done as part of reviewing and publishing . when an initiative needs to get one of the specific archetypes published. Further discussion in the next meeting. |
...