Implement CIEL QA workflows

[paynejd]

Implement workflows in CIEL Labs to complete QA review of all remaining CIEL concepts (~15k) for consistent naming, up-to-date mappings, and other QA checks. Specifically, this includes the OpenMRS Validation Query and converting 4 existing CIEL Lab pages into versions that are connected to the OCL API back-end.

Knowledge

• Become familiar with the OpenMRS validation script

CIELAdmin

• Create a Release > Validation page to verify the OpenMRS schema
• Migrate functionality from CIEL Lab V1 → V2 (CIELAdmin as source of truth):
  Consistent naming convention – Casing consistency
  (Work already in progress: ~15k concepts to check manually — a transversal task that will take months, so the feature must be created and configured early.)
• Migrate functionality from CIEL Lab V1 → V2 (CIELAdmin as source of truth):
  Translation (Portuguese and French) with pre-translation support using:
  mlx-community/Bio-Medical-Llama-3-8B | DeepL API | Qwen3-8B | mlx-community/TowerInstruct-v0.1-bfloat16-mlx
• Migrate functionality from CIEL Lab V1 → V2 (CIELAdmin as source of truth):
  Mapping with pre-loaded suggestion batches, similar to the ~11k CIEL → ICD-11 suggestions already generated using Claude Opus

OCL

• Evaluate and implement migration of the CIEL Lab V2 QA features to OCL as source of truth:
  Casing consistency → possibly move to Release Checks
• Evaluate and implement migration of Translation QA from CIEL Lab V2 to OCL as source of truth
• Evaluate and implement migration of Mapping with pre-loaded batch suggestions to OCL as source of truth

[filiperochalopes]

@paynejd @jamlung-ri Please let me know your thoughts. I am already working on:

Migrate functionality from CIEL Lab V1 → V2 (CIELAdmin as source of truth): Consistent naming convention – Casing consistency

Should I go ahead and create a subtask for it as ~In Progress?

[askanter]

Not sure why the last CIELAdmin V1 page is being migrated if we are implementing that functionality in the Mapper tool. The only part that is different is the fact that we are pre-loading matches as opposed to running automatch. What additional value would a lab page bring? I suppose we are still waiting on the Mapper being run using a Repo instead of a file, so that functionality it needed if we are to continue to easily map CIEL to ICD-11.

[filiperochalopes]

@askanter Time and cost–benefit were major factors here.

We processed around 11k mappings using Claude Opus (Anthropic’s most capable — and most expensive — model), which required a considerable amount of time (remember 20s per concept) and resulted in a significant token cost.

You may remember that I had a large number of "free" tokens available for a short period because of another project I was working on in Brazil, and they were set to expire within a week — so I used most of them for this task.

Beyond that, the abstraction is generic enough to work for any preloaded batch, not just CIEL → ICD-11.
For example:

• future IMO batches (if provided),
• additional datasets,
• or experimental algorithms not yet integrated into OCL Mapper.

In other words, the infrastructure is reusable and not tied to a single workload.