Feature request: trade-name synonyms for existing codes (Korean list ready) + Unicode-safe name generalisation

[tori0513]

Thank you for the package — we use as.ab()/as.mo() in an antibiotic-stewardship tool for Korean hospitals.

Korean prescription exports carry product names, e.g. 타조신주 4.5g (Tazocin), 유한메로펜주사 0.5g (meropenem), 로세핀주 1g (Rocephin). Today as.ab() cannot resolve them, for two structural reasons:

1. generalise_antibiotic_name() replaces every character outside [A-Z0-9 -)(] with /, so any Hangul (or CJK/Cyrillic) alias collapses to slashes before matching.
2. add_custom_antimicrobials() refuses codes that already exist (stop_if(any(x$ab %in% AB_lookup$ab))), and only name is added to generalised_all — so there is no supported way to attach extra synonyms to an existing code such as TZP.

Proposal (happy to send a PR for any of these):

• (a) add_custom_antimicrobial_synonyms(ab, synonyms) (or accept an existing ab in add_custom_antimicrobials() when only synonyms are supplied), appending to synonyms/generalised_synonyms for that code.
• (b) Make generalise_antibiotic_name() keep letters of any script ([^\\p{L}\\p{N} -)(] with perl = TRUE) so non-Latin aliases survive; existing Latin behaviour is unchanged.
• (c) Optionally, a AMR_custom_ab_synonyms option mirroring AMR_custom_ab, so a site can point to a CSV/RDS of trade names.

We have a ready, licence-clean table: 2,539 Korean product names/brand stems → 24 EARS-Net codes, derived from the Korean HIRA drug master (public data, KOGL-1) with a no-guessing rule (ingredient tokens or generic-name code must map exactly; collisions dropped; word-start matching so that 펜타조신/pentazocine does not hit 타조신). Repo: https://github.com/tori0513/kr-antimicrobial-tradenames. We would keep it updated quarterly with the HIRA release.

Would you accept (b) as a small PR first, and how would you prefer (a) to look?

[msberends]

Hi, thanks for using the package!

We must give this some thought. Adding synonyms is absolutely useful. Having non-ASCII characters in user-faced datasets is forbidden by CRAN, so we can't store them in the antimicrobials data set.

add_custom_antimicrobial_synonyms is therefore a useable alternative. A PR would be very welcome. The ab codes should be tested against AMR_env$AB_lookup$ab, as that is the collection that holds all agents, including the ones that were manually added by a user.

[tori0513]

Thank you — that makes sense, and keeping non-ASCII out of the package data is fine for us: the Korean list stays in our own repository, and users would load it with the new function.

Plan for the PR:

add_custom_antimicrobial_synonyms(ab, synonyms) — ab validated against AMR_env$AB_lookup$ab, so user-added agents work too; the synonyms are appended to synonyms, generalised_synonyms and generalised_all for that code, previously coerced values for those codes are reset, and clear_custom_antimicrobials() removes them again.
One detail from reading as.ab(): the input is transliterated with iconv(..., "ASCII//TRANSLIT") before generalisation, so Hangul is already gone before any lookup. We would check user-added synonyms against the input just before that step (case-insensitive, whitespace-normalised) and leave the existing pipeline unchanged — which would make (b) unnecessary. Would that be acceptable?
Tests would use \u escapes only, so the source stays ASCII.

Happy to adjust names or scope to whatever fits the package best.