Extending Code Lists

When generating the RMIM assemblies, GPMR will parse the vocabulary MIF files and keep an internal representation of the value sets, code systems and concept domains that properties are bound to. When generating C# or Java GPMR will determine the best way of representing the value set in code.

• If the Value Set or Code System is not complete (i.e. is marked partial) then any properties bound to said value set carry a type of CS<String>, CV<String>, etc.
• If the property or Value Set is marked CWE (extensions allowed) then the the property is bound to String as well.
• If the Value Set is made up of an expression and not all expression components can be found (i.e. intersect X and Y where Y is not available) then the property is bound to String
• Otherwise, enumerate the literals in the value set and bind the property to an Enumeration (or IEnumeratedVocabulary in Java)

That last bit is usually the sticky point. Some jurisdictions ignore the CWE strength and add codes of their own (I have seen custom realm codes, custom null flavors, all kinds of weirdness in our travels).

In order to overcome this Everest (and jEverest) provide a relatively easy mechanism for assigning “non standard” codes to properties. For this example, let’s say we want to assign a custom ProcessingID of “Sample” (a bit contrived but it illustrates the process). To assign our ProcessingID of “S” we’d do this in .NET:

PRPA_IN101103CA sample = new PRPA_IN101103CA();
sample.ProcessingCode = Util.Convert<CS<ProcessingID>>("S");

In Java the process is a little easier as jEverest uses IEnumeratedVocabulary so we can just add the code:

PRPA_IN101103CA sample = new PRPA_IN101103CA();
sample.setProcessingCode(new ProcessingID("S", null));

The result is a (non standard) XML instance carrying our custom code:

<processingCode code=”S”/>