Proposal: Creating a codelist-editor Library

[CarolineMorton]

Why Create a Sister Library?

Separation of Concerns:
The existing codelist-rs focuses on core functionality: managing metadata, options, and code entries, as well as serialisation (e.g., saving to CSV/JSON) and validation.

A codelist-editor can handle all tasks related to creating, modifying, and commenting on codelists, without bloating the core library. It is something that not every user will need.

Extendability
By splitting the functionality at this stage, we can possibly add collaborative editing in the future. I would like this aspect of the tool to become something like www.opencodelists.org but that can be used locally. The plan for this is to create a react/esbuild app in the future that contains a UI to do this.

Proposed responsibiltiy of codelist-editor

This suggestion leans on this paper which goes through the sorts of data that should be recorded with a codelist.

Code functionality and modules

1. Editor API - high level API for creating, modifying and in general managing codelist
2. CodeEntry Editor - handles individual code entry operations like adding comments, editing terms - we may want this to interact with a future planned codelist-mapper functionality
3. MetadataEditor - updates and manages metadata fields
4. Produce logger MD file - one of the epidemiologists wanted to be able create a way for any changes or information on the codelist to be outputted as a markdown file. I think we should be able to faciliate this.

First steps

• Edit metadata in codelist-rs to add:
  • created date
  • last modified date
  • purpose
  • target audience e.g. adults, hospitalised in patients, children
  • use context - e.g. hospital/secondary care, primary care, other
  • reviewed - bool - has the codelist been reviewed?
  • Reviewer
  • Review date
  • Status - validated, editing/in progress/draft, finished but unvalidated
  • valdation notes
  • tags - liek diabetes
  • license
  • usage - list of papers/or publications where usd
  • contrubitor list

I have excluded concepts covered as i think this should be in purpose and descritpion.
I suggest we split metadata so that we have something like:

pub struct Provenance {
    pub source: MetadataSource,          
    pub created_date: Option<String>,    
    pub last_modified_date: Option<String>, 
    pub contributors: Option<Vec<String>>, 
    pub license: OPtion<String>
}

and addition structs for PurposeAndContext, ValidationAndReview, and CategorisationAndUsage