The Profiled Operational Template

A 'profiled' OPT is a technical artefact intended for direct use in some context. It is a processed form of the raw OPT in which various removals of unwanted elements are made, and terminology references are converted to the desired form for final use. Multiple profiled OPTs can be derived from a raw OPT.

It is assumed that tools provide ways of specifying the various alterations, and they are not described here. the following describes only the resulting output.

Annotations Removal

Annotations can be removed from a raw OPT, which results in the complete removal of the annotations section in the output.

Language Filtering

Since archetypes and templates in general may contain numerous language translations, and the target deployment environment is normally targetted to only one or two languages, one of the filtering possibilities is to remove any of the languages (including the original authoring language) up to the limit where only one remains.

The resulting OPT will be of the same form as before, but with reduced language translations. In the language section of the archetype, the original_language property will either contain the original authoring language of the root source template (which could easily be different from that of the majority of referenced archetypes).

Terminology Binding Filtering

Terminology bindings can also be globally filtered out in the profiled OPT, up to removal of all bindings. The resulting OPT will contain only those bindings not specified for removal in the terminology section.

Terminology Substitution

A more complex aspect of terminology-related processing has to do with what final codes will be used in archetype data. In the source artefacts, two types of value coding occur. The first case is fields constrained with archetype local value sets, i.e. where the ac-code maps to a group of at-codes, or a single at-code is specified. The second case is where ac-codes are bound only to external value sets (often large ones, such as 'type of infection'), and the value recorded in the data for that field must be an external code of some kind.

The first case poses a possible choice - either archetype-local at-codes or external codes could be used. The choice of what terminology should be used for each ac-code that is bound to both an internal and an external terminology could be made in several places, depending on the level of fine-grained control needed.

  • If we only need to choose which terminologies are allowed at whole-of-library level, the choice is effect by choosing terminology bindings to be removed, as described above.

  • If we need to decide on a per-OPT basis, i.e. the allowed/required terminologies may differ from one OPT to the next, it can still be an input to the OPT profiling step, but now it will be an argument specific to each OPT.

  • If node-level control is needed, the choices would need to be made in the raw OPT. Note that while it is normal that some nodes be coded by one terminology, e.g. an HL7 vocabulary, and others by e.g. SNOMED CT, node-by-node selection is not needed to achieve this, because the bindings for those nodes will already state the allowed possibilities. Node-by-node choosing is only needed if there is a need to further reduce possibilities to a more limited set, e.g. if within a single template, one node has a binding to both ICD10 and SNOMED CT but in a specific use, should only be coded in ICD10, but another node exists for which only SNOMED CT should be allowed, from the same two original possibilities.

TBD: Currently there is no way to do this in ADL2. It would be easy to implement, using a set of paths of coded nodes each with the list of terminologies allowed at that point.

The result of the choices, however made, is expressed in the profiled OPT by using a modified form of the normal term constraint syntax. This is described in detail in the ADL specification, in the Terminology Constraints and Terminology Integration sections.