Map maker manager

From Discovery Data Service
Jump to navigation Jump to search

The map maker manager application enables the authoring and storage of maps for use by the mapping server.

In authoring maps, mapping can be seen as a work flow whereby a map is built from some previously authored maps, perhaps added to with some new maps, and perhaps further modified.

Techniques involved include convergent maps and mapping chains.

Convergent map authoring

When authoring a map, the map can be seen as a set of interconnected nodes, each node being triggered by the passing in of one or source objects, or the outputs from other nodes, finally resulting in the output of a target object for use by the calling application. Nodes accumulate maps, in effect inheriting maps from other maps. This can also be conceptualised as splitting of source classes followed by merging, until in the end a single map is generated.

Mapping convergence is the means by which there is an attempt to rationalise the huge number of source types to a fewer number in order to make map authoring simpler and more efficient.

For example, let us say that we are trying to map a drug code from an EMIS drug issue to the common model. We understand that the code comes from Chrisp Street Health Centre, which uses EMIS Web, and the source table in question is the Prescribing issue table, with field of Codeid, and the code value is '12345'.

Likewise, we are also trying to map a drug code from a TPP practice source. We understand that the code comes from the Parkdale medical centre, that they use TPP SystmOne, that the source table in question is the PrimaryCareMedication table , the field is code and the id is 232000001108.

We also know that EMIS provides a look up table between their code and DM&D, but SystmOne provides the DM&D code itself.

The first thing we recognise is that the context of the above two sources appears to be nearly equivalent. Both are going to end up in the same target class and both will end up with the same target value when mapped from DM&D. There is a variation in EMIS in that before getting to exactly the same context, there is a prior step to perform, the map between EMIS 'X' and the DM+D 'Y'. However, if that mapping were to occur first, then the two context's would be exactly equivalent.

It appears that there is some form of convergence from two sources. This can be illustrated in the following way:

Convergent context.jpg

Convergence can occur in both class mapping and value mapping. the net result of the convergence approach to authoring is a single source to target map which is rendered as   

Mapping chain

When authoring a map, the map author chains together a series of actions and calls the relevant nodes with the relevant source data properties (or simply passes on the results of a previously triggered node). Thus a chain is built up.

Because of the convergence concepts, it is likely that the same node will be used in many different mapping chains, and it is equally likely that the same chains will be used by different source systems. It is possible to configure maps that ignore particular source identifiers. For example to process an EMIS observation entry, the provider id would be ignored as the only relevant context is the type of system. The provider property would be set to ALL in the mapping configuration.

Mapping node


'Domain mapping node' sums up the idea that a number of different source structures can in the end converge and map to a single target structure, by dint of the common domain in which the map occurs, and the common context in which a particular set of sources share.

The primary object is the 'Domain mapping node' which has a uniquely identified context to which a number of sources map to. Each different source is referred to as a 'Input slots' and all slots must be filled for the map node to be triggered.

A mapping node is authored over time, perhaps initially by selecting a single source, but then recognising that additional sources are able to converge.

In the above example, the author has decided that there us similarities between the EMIS and TPP prescription tables. A node can be created with a set of properties that indicate a convergence sufficiently to know that the output is class and property. For example:

An example mapping node configuration that deals with some inbound medication
{ "MapNode": [
      {"IRI": ":MN_GPMedRequests",
        "Domain": ":InboundPublisherMaps",
        "Description": "Common convergence for source GP medication issues",
        "MapSlot": [
            "Property": "Source_Provider"},           //No Value therefore any provider will do
            "Property": "System",
            "Value": [ "EMISWeb","SystmOne"]},
            "Property": "Table",
            "Value": ["PrescriptionIssue", "SRPrimaryCareMedication"]}],
        "AddOutput": {
          "Class": ":DM_MedicationRequest",
          "Property": ":DM_requestedMedication" } } ],

We see here that if any provider, using EMIS Web or SystmOne as their source, if the source table is either Prescription issue, or SRPrimaryCareMedication then we are going to end up eventually with the same context and a class of medication request and a property of requested medication.

We have yet to deal with the remaining EMIS value problem. To do that we create another node to deal with the EMIS variation, which only requires the Codeid and the value as input slots.

This node calls a mapping function with the three parameters one of which is the property value of the input property

A simple mapping node with a property code look up

  {    "IRI": ":MN_EMISCodeIdLookUp",
        "Domain": ":InboundPublisherMaps",
        "Description": "Look up for EMIS code id",
        "Input": {
          "Property": "CodeId"},
        "MapFunction": {
          "Name": "CodeMap",
          "Parameter": [{
              "Fixed": "EMISCodeId"},
              "PropertyValue": "CodeId"},
              "Fixed": "DMD"}] },
        "AddOutput": {
          "Property": "Drug",
          "FunctionResult": "true"} } ]}

We are now ready to converge the two outputs into the final node, which only has to do the final map.

The final mapping node in the chain performing a concept look up
{ "MapNode": [
        "IRI": ":MN_IMMedicationrRequestEMISTPPDrugMap",
        "Domain": ":InboundPublisherMaps",
        "Description": "Convergence nodes for medication requests from EMIS and TPP",
        "Input" :[
         {"MapNode" : ":MN_GPMedRequests"},
         {"Property": "Drug"}],
         "MapFunction" : {
        "AddOutput": {
           "Add":{"FunctionValue": true } } ]}

Cumulatively, the result of the map contains the target class, property and value as well as the context node identifiers that generated it. The final target output to the client being the map result set

 "MapResultSet": {
  "MappingShortcut": {
   "ShortCutNode": ":GPMedRequests",
   "RequiredProperty": ["CodeId"]},
  "Class": ":DM_MedicationRequest",
  "Property": ":DM_RequestedMedication",
  "Value": ":SN_123300212120"

Of significance is the 'Mappint short cut' produced as part of the result. This is a performance enhancing value that can be used by the client in the next API call to speed up the response. If the client is confident that the class and property are going to be the same (as a result of being the same source table and field then only the property name and value need be submitted.

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. In other words by mapping in two stages we get a series of one to one maps which appear to be one to many

To more easily demonstrate how mappings work, there is a working example showing a walk through of the use of the mapping API using the resource examples illustrated below