Templates are aggregations of archetypes to fit a particular data entry situation. Templates also allow us to further specify what is required. It will usually be appropriate to link the template to a terminology subset rather than an archetype as archetypes may be used in many different settings. Sometimes the archetype will have a place holder for a binding to a particular terminology. There will be a number of requirements that may be specifically required when designing a template in a particular setting.

Template level requirements for working with terminology

1. Ensuring a code is only drawn from one particular terminology

It will be common at a particular location that coding will be drawn from a particular terminology. This may be achieved at an application level - in openEHR the term Palette is used to describe repository level commitments to language, locale, default terminology etc. It may also be achieved by limiting the choice of terminology to SNOMED-CT or ICD10 for instance. This can be achieved at the level of the template and may be the only restriction, allowing free text as an alternative. In the Ocean Template this would be achieved by providing the whole of SNOMED-CT as the source and setting LimitToList to false, allowing free text to be added if required.

2. Working with a particular terminology server

In a working environment, people building templates will work with a particular terminology server to provide the the set of terms available to a particular data point. This may involve quite arbritary syntax and requirements and may accept parameters at the time of calling the service.

Template specification

The openEHR Template specification may have an extendable T_DV_TEXT to provide for these requirements. The class will allow for setting just the terminology, allowing free text overrides and locale specific extensions using name value pairs to cater for using specific terminology services.