ShExMap

Why do we need domain models?

Domain models will likely be more principled in their design and will definitely be more intuitive the physical models involving constellations of observations. A DAM is an example of a domain model which is tailored towards capturing the aspects which are required for analysis, e.g., aspects pertinent to workflows or business processes. A class and relationship hierarchy such as that implemented in ActRelationship type codes will be more simply expressed in an RDF ontology and will leverage existing RDF tooling for model and example verification.

Available DAMs

Projects like CIMI engage clinicians in the development of intuitive domain models, e.g. a blood pressure and a structure with a measurement of a systolic and distolic pressure, and maybe some other stuff like posture or device. Here are a few CIMI models:

• blood pressure
• APGAR
• full blood count panel

DAM as Ontology

Ideally, development of little DAMs would include identifying all of the intersections between them, creating a more comprehensive DAM, and ontology of clinical artifacts. The body mass used in an estimated glomerular filtration rate is the same as the body mass used in a body mass index. A useful clinical ontology in RDF would capture that by reusing the same identifiers wherever the same concept was reused.

Why do we need mappings?

• Definitions for physical representations — presuming the DAM has intuitive and useful semantics mapping a physical model to a logical model provides clear guidelines for implementors who need to work with the corresponding physical models. These take the place of implementation guidelines or instance diagrams.
• Duplication detection — if two domain models map to the same physical model, either the models are incomplete or they duplicate each other. This will be tempered by the fact that any models that share components will necessarily map to the same physical model.
• Data/query transformation — mapping between a physical model and a logical model provides users of the logical model, for instance, someone writing clinical decisions support rules, access to working clinical data. Mappings between a logical model and two or more physical models enables mappings between those physical models.

Mapping mechanism

As the models are described as ShEx schemas, the mappings between them are captured as shared "variables" in a %map:{ %} extension. These variables are given full URLs which enables trivial disambiguation, as well as leveraging standard prefix conventions for easier lexical categorization.

Blood pressure example

Blood pressure measurements provide an intuitive example of measurements with associations. Each measurement includes (at least) a systolic and diastolic reading. Transforming multiple such measurements requires preserving the associations (see section below); a bag of systolic and a bag of diastolic readings is not sufficient.

To see ShExMap performing this (and more complex) mappings:

1. click the try it link (maybe open in another window).
   On the left you will see an empty schema input, and on the right an empty data input.
2. click the BP button in the manifest below the schema.
   This will populate the schema and make some data buttons available to the right of the manifest.
3. Select the simple data button.
   This will populate the data and the QueryMap.
4. Click validate (ctl-enter) under the data seletor. This will validate the input data against the input schema.
5. Scroll way to the right with the horizontal scroll bar just above the validate button
   This will reveal a three new text areas: bindings from validation, static bindings, target schema.
6. Click the materialize (ctl-\) button
   This will use the bindings from validation to materialize the target schema.
   The triples will replace the results at the bottom of the page.

<BPunitsDAM> {
    :systolic {
        :value xsd:float %map:{ bp:sysVal %},
        :units xsd:string %map:{ bp:sysUnits %}
    },
    :diastolic {
        :value xsd:float %map:{ bp:diaVal %},
        :units xsd:string %map:{ bp:diaUnits %}
    }
}
            

<BPnormalizeDAM> {
    a (:CanonicalBloodPressure),
    :systolicBPmmHg xsd:float %map:{ cast(bp:sysVal, bp:sysUnits, "mmHg") %},
    :diastolicBPmmHg xsd:float %map:{ cast(bp:diaUnits, bp:diaUnits, "mmHg") %}
}
            

<BPfhir> {
    a (fhir:Observation)?,
    fhir:coding { fhir:code (sct:Blood_Pressure) },
    fhir:related { fhir:type ("has-component"), fhir:target @<sysBP> },
    fhir:related { fhir:type ("has-component"), fhir:target @<diaBP> }
}
<sysBP> {
    a (fhir:Observation)?,
    fhir:coding { fhir:code (sct:Systolic_Blood_Pressure) },
    fhir:valueQuantity {
        a (fhir:Quantity)?,
        fhir:value xsd:float %map:{ bp:sysVal %},
        fhir:units xsd:string %map:{ bp:sysUnits %}
    },
}
<diaBP> {
    a (fhir:Observation)?,
    fhir:coding { fhir:code (sct:Diastolic_Blood_Pressure) },
    fhir:valueQuantity {
        a (fhir:Quantity)?,
        fhir:value xsd:float %map:{ bp:diaVal %},
        fhir:units xsd:string %map:{ bp:diaUnits %}
    },
}

Issues

• glue between heads and bodies

  In principle, shared variables are enough to associated rule heads with rule bodies. We need to test this with compositions in which a DAM uses variables bound in multiple physical models (e.g. a body mass in a BMI) and multiple DAMs used the same variables (e.g. BMI and EGFR).

• n-ary predicates

  Mapping directed, labeled graphs to familiar n-ary predicates for use in e.g. Quick (CQL).