Overview
Documents a recommended approach to an "editing cycle" for a mapping project when the mappings are released with the underlying source terminology version.
Prerequisites
The first editing cycle starts with creating the initial infrastructure for a mapping project. This involves
- Creating and editing the map project metadata
- Loading versions of terminologies involved (source and destination)
- Loading mappings from legacy environments
- Running the "begin editing cycle" mojo.
Only with a properly configured environment does it make sense to talk about a natural editing cycle.
Editing Cycle
The diagram shows how a typical editing cycle could work along a time axis where the diagram starts over once it reaches the end.
The important things to note are:
- t0: At the beginning of an editing cylce, the correct version of the source terminology is loaded (destination terminology update is on a different cycle)
- An editing cycle is initiated by calling the "begin editing cycle" mojo (see Release Processing Tools).
- t1: this may overlap with t0 and is when editors begin editing for the following release version
- deltas: the delta symbols reflect the use of a process to incrementally update the source terminology during the editing cycle.
- For the "SNOMEDCT to XXX" projects, this process is called the "drip feed" and is handled by processing incremental RF2 deltas.
- t2: this is where the destination terminology version might change, in the middle of an editing cycle.
- This process involves identifying target codes that are no longer valid and re-mapping them (thus "re-edit for change")
- It also may involve identifying target codes that have new children or siblings or other terminology changes that may warrant re-editing.
- t3: this is where editing to accommodate the destination update termionlogy begins. Note, the continuing processing of deltas is an independent process and simultaneously drives editing workload.
- t4: All planned content for a release is edited to completion at this point and a process "begins" the release.
- this process verifies the state of the database is ready for release and retires mappings for concepts that are obsolete, or for other reasons no longer in scope.
- t5: This is when generation and QA of release files takes place and can be iterative until problems are refined.
- If desired, editing can continue during this phase, but it is recommended that a cut of the database be used to perform the release independently of continued editing.
- t6: When ready, an explicit "finish release" process is used to align the internal representation of the release view of the mappings (e.g. ComplexMapRefSetMembers) with the actual release. This is most easily accomplished by simply loading the actual release file into the system, thus replacing prior version records.
References/Links