Data map API

The mappings package is one of the 5 main component categories in the information model.

For the information model to be even more useful than simply a reference, it is helpful to map the constructs in the core information model to concrete implementations of data bases that hold data.

These maps support the automation of data population and retrieval, either via generation of the implementation specific data manipulation language (e.g. SQL or CYPHER), or by the parameterisation of application functions used by code.

Maps (or mappings) require three main types of resource:

1. A source resource. i.e. the thing that is mapped from
2. Intermediate data manipulation rules that operate on the data between source and target
3. Target resource. i.e. the thing that is mapped to from the source

Mapping pipeline

As the information model takes data from many sources and maps to an abstract common model. The core databases in Discovery itself represents the common model via a set of implementation specific schemas. Thus the core Discovery data schemas are themselves mapped from the core model.

Thus mappings may be used both by subscriber databases and publisher databases and both inside and outside of Discovery.

Furthermore, it can be seen from the logical 2 step mappings that it is equally practical for clients to consider a direct map from source to destination knowing that it has mapped to the common model as part of the process. This contrasts this style of mapping to conventional integration mappings that map from many to many directly.

Implementation schema resources

DB Schema class

Before doing any mappings, it is necessary to model a target schema in order to map to it.

Implementation schema resources are a set of objects of the class DBSchema (to the right)

The class is designed as a simple entity relationship class with 2 additional properties:

1. The name of the table's extension tables. These are optional triple tables designed so that a schema can continue to extend to additional properties and values using the information model to determine the properties and data types. This avoids the need to continually change the relational schema with new data items.
2. The name of the field holding the subtype indicator. This is described as the entity subtype attribute.

The following is an example of a snippet from an encounter table:

A schema table example showing extension table and subtype field

{"DBSchema": {
      "DBSchemaName": "Compass_version_1",
      "DBTable": {
        "DBTableName": "encounter",
        "DBExtensionTable": {
          "DBTableName": "encounter_extension"
        },
        "DBSubTypeField": "type" } } }