Have to find a solution for 9 million product numbers

[halcwb]

Some products are made locally, so do not appear in the Z-index. Need to manually add these products.

[github-actions]

🤖 This is an automated response from Repo Assist.

This is a classic "local formulary" challenge. A few thoughts on practical approaches, building on the existing architecture.

Current situation

Products are keyed by their Z-index product number (a 7-digit integer). Locally manufactured items have no Z-index entry and therefore no key that fits the existing scheme.

Approaches

1. High-range product numbers — Reserve a block above the Z-index maximum (e.g., 10_000_000+) for locally manufactured products. Simple, zero-schema change, easily detectable. The downside is it's a convention rather than an enforced type distinction.

2. Negative product numbers — Use negative integers as a namespace for local products. Same trade-offs as above but arguably clearer since negative Z-index numbers are never valid.

3. Discriminated union product identifier — Replace the raw integer key with a DU:

   type ProductId =
       | ZIndex of int       // standard Z-index product
       | Local of string     // locally defined (e.g. hospital code + name)

   This is type-safe and self-documenting. The downside is a larger refactoring footprint.

4. Supplementary sheet in Google Sheets — Add a "LocalProducts" sheet alongside the existing Z-index data. The loader merges local and Z-index products at startup. Local entries get synthesised IDs (option 1 or 2). Keeps the data model simple while supporting the workflow.

Recommendation

Option 4 combined with option 1 (high-range IDs) is probably the lowest-risk path: it requires a new sheet/column mapping but no type-system changes. The local products can be authored and updated with the same Google Sheets workflow as the rest of the formulary.

If the codebase is being refactored anyway, option 3 is the cleanest long-term solution.

Curious whether there's already a hospital-specific product code in use that could serve as the local identifier.

Generated by Repo Assist

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@f2c5cf1e4af58e09a93ba0703c6bf084711b265f

[halcwb]

This should be a two-level solution:

1. Product codes that only exist local in the pharmacy system should be handled by the type ProductId = | ZIndex | Local at the GPK level. However, this also would require getting the product information from the local pharmacy formulary.

2. At the GenFOM level there now is a entry in the Formulary sheet to add extra products:
   Sample data:

GPKODE	Type	UMCU	ICC	NEO	ICK	HCK	Generic	UseGenName	UseForm	UseBrand	TallMan	Mmol	Divisible	GStand	Form	Brand	GenName	Unit	Energy kCal	Carb g	Prot g	Lip g	Sod mmol	Pot mmol	Calc mmol	Posph mmol	Magn mmol	Chlor mmol	Iron mmol	VitD IE	IsReconste	IsDilute	IsAdditive
104299	medication						ACETYLCYSTEINE							ACETYLCYSTEINE	OOGDRUPPELS		ACETYLCYSTEINE
Samenstelling C	parenteral	x	x	x	x		Samenstelling C											mL	0.32	0	0.08	0	0.008	0.02	0.028	0.024	0.008	0.072	0	0	FALSE	FALSE

We can use both options or only option 2. However, option 2 doesn't support products with substances other than specified in the columns. The column substances are additional ingredients that will be included in the totals calculations.

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for the clarification, @halcwb! This is very helpful context.

So the two-level architecture makes sense:

Level 1 — Type-safe product identity (ProductId = ZIndex | Local): For locally manufactured products at the GPK level, a DU-based identifier ensures the type system distinguishes local from Z-index products. This is the cleanest long-term design.

Level 2 — Formulary sheet: The existing Formulary sheet already handles the data side — locally defined entries can sit alongside Z-index-derived entries. The sample data you've shown (e.g., Samenstelling C) maps nutritional totals rather than substance-specific ingredients.

The constraint you've identified — that the Formulary sheet columns only cover predefined nutritional substances — seems like the main open question. For a locally manufactured medication with a unique active substance not in those columns, a separate mechanism would be needed.

Practical path forward (my read):

• Short term: use the Formulary sheet for local TPN compositions and simple compounded preparations (adequate for most local products today).
• Medium term: adopt ProductId = ZIndex | Local in parallel, so the type system can enforce the distinction without schema changes.
• Long term: if locally manufactured products need substance-level dose tracking, extend the sheet or add a dedicated local-substances sheet.

Does this match your thinking? And is there a particular hospital product that's blocking a current workflow, or is this forward-planning?

Generated by Repo Assist

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@f2c5cf1e4af58e09a93ba0703c6bf084711b265f

[github-actions]

🤖 This is an automated response from Repo Assist.

I've created a prototype script to help with the "Level 1" part of your two-level solution: src/Informedica.GenFORM.Lib/Scripts/LocalProducts.fsx (in a draft PR — title: [Repo Assist] feat(genform): LocalProducts.fsx prototype for type-safe local product support).

What the prototype covers

1. ProductId DU — ZIndex of int | Local of string to make the distinction explicit in the type system.
2. ProductId.parse — replaces Int32.tryParse in the Formulary sheet loader; classifies each GPKODE as Z-index or local.
3. LocalMedication.create — builds a Product record from Formulary sheet columns for locally manufactured medications (analogous to the existing Parenteral.create/Enteral.create).
4. Extended Medication.get — handles both Z-index and local products in one pass.

What it doesn't cover

• The "Level 2" substance column limitation you noted: locally manufactured medications with active substances not in the predefined nutritional columns would still need an extended approach (a separate substances sheet, or additional Formulary columns).
• The migration path for existing code that currently holds GPK as int or string throughout the stack.

The script is purely in Scripts/ and makes no changes to source files, per project policy. Happy to adjust the prototype based on your feedback — for instance, if the ProductId DU should live somewhere else, or if the Local case should carry more metadata.

Generated by Repo Assist

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@f2c5cf1e4af58e09a93ba0703c6bf084711b265f