## 4 Results  
Defining and modeling an augmented EHR is a design process that entails performing tasks manually. However, once an augmented EHR is defined for a given initial EHR archetype, it can be applied to any instance of that initial EHR archetype. This section presents the design of a software prototype to run the data exchanges and queries needed to generate augmented EHR extracts from the initial EHR extracts. The workflow (Figure 9) starts from the initial EHR extract and the identifier of the augmented EHR, and finalizes by returning an augmented EHR extract. The _Extraction_ module identifies and obtains the EOI values from the initial EHR extract. The _Augmentation_ module takes the EOI values as inputs, and executes the procedure described in the section Materials and Methods (B) to build the EOI binding triples. These triples are injected in the query graph of a SPARQL query to obtain the augmentation content from a LOD dataset, as stated in section Materials and Methods (C). The augmentation content is normalized according to the augmentation archetype (section Materials and Methods (D)). Finally, the _Integration_ module generates the augmented EHR extract starting from the initial EHR extract and the normalized augmentation content, as described in section Materials and Methods (E). A software prototype was implemented using the XQuery scripting language to develop the _Extraction_ module, the _Integration_ module, and specific steps performed by the _Augmentation_ module such as the building of the EOI binding triples and the normalization of the augmentation content. The benefits of using XQuery are, first, to take advantage of the transformation scripts that the LinkEHR platform generates when compiling mapping specifications (i.e., data exchange 1 and 2 at data level in Figure 1); and, second, the fact that XQuery is designed for the extraction and manipulation of XML data eases the tasks of extracting EOI values in the _Extraction_ module and the building of EOI binding triples in the _Augmentation_ module. Additionally, the SPARQL query language is employed in the _Augmentation_ module to obtain the augmentation content, and Java programming language is used in the prototype to orchestrate the workflow and communications between the involved modules. Figure 8: Archetypes’ visualization from LinkEHR. (**a**) The initial EHR archetype _CEN-EN13606-ENTRY.Medicacion.v1_. (**b**) The augmented archetype _CEN-EN13606-ENTRY.Medicacion.v1_. Finally, this prototype also includes a repository of available EHR augmentations, which is omitted from Figure 9 for the sake of clarity. For each EHR augmentation, this repository holds:  
* (I) The XQuery script to build the EOI binding triples starting from the EOI coded values
* (II) The SPARQL query to collect the augmentation content
* (III) The augmentation archetype
* (IV) The XQuery script to normalize the augmentation content according to the augmentation archetype
* (V) A list of initial EHR archetypes this augmentation may enrich. For each initial EHR archetype, the repository contains:  
* Archetype paths pointing to the EOI elements in the initial EHR archetype, required to extract EOI coded values from initial EHR extracts
* The augmented archetype
* The XQuery script to generate augmented EHR extracts starting from initial EHR extracts and normalized augmentation contents  
To set up new EHR augmentations in the prototype requires manually adding this information (I through V) to the repository. The prototype is intended to be integrated with an EHR system in compliance with EHR archetype-based standards. The integration  
Figure 9: Description of the process to obtain an augmented EHR extract (i.e., execution cycle of the augmented EHR). 1. _Extraction_: Reads the EOIs specified by paths and provides them to the _Augmentation_ module. 2. _Integration_: Generates instances of the augmented archetype by combining the EHR archetype instance and the augmentation archetype instance. must be carried out by IT professionals.