Entity subtype attribute

Within the ontology, a data model entity may be a subclass of another data model entity, which means that the sub-entity is a more specialised class than its super entity. The sub-entity will have a number of business purpose specific attributes, defined according to the healthcare business they are used in.

When implementing a data model entity in a relational or graph database, it is extremely unlikely that an implementer would create one table or one node type per entity. There would be potentially thousands, many of which would have identical properties and thus breach basic relational normalisation rules. Even where entities have slightly different attributes, it is unlikely that an additional table would be produced for each. More likely some form of extension capability such as a key value pair or triple table would be used.

Implementers would probably create a few high level tables to which many scores of sub-entities would map. A solution must be found the problem of  sub-classing in the data model versus database tables or node types.

Consider the following intuitive statements.

1.       An accident and emergency attendance is a type of health event.

2.       A blood pressure recording is a type of observation.

To indicate the sub type, most implementers would implement a field that dictated the type or code a ‘type field’ or ‘code field’ as FHIR does.  To apply this a special mapping property type ‘Sub Type property’ is defined in the data map.

This can be relied on to drive business logic when populating or querying a record. In the above example, the following could be stored in the actual record entry:

 

Table	Field	Value
Encounter	type	Accident and emergency
Observation	type	Blood pressure

The following could be found in the IN to schema map.

{"Mapping": [
      {
        "IMSource": {
          "IMClass": ":DM_Encounter"
        },
        "DBTarget": {
          "Schema":"Compass_version1",
          "Table": "encounter",
          "SubTypeField": "type" } }}

This is in effect a tautology as it says that an encounter table has a type field whose value is an encounter!

On other words, the implementation map can make full use of the entity sub type hierarchy when mapping and searching the records,  knowing that subtypes are indicated using the mapped ‘Entity Type property’, and  can deduce the pattern of the data to be processed.

In the blood pressure example, the data model would probably be authored as follows:

 {Entity:[{
          "IRI": "DM_Obs_SystolicBloodPressure",
         "Relationship":[ {
             "IRI"="RM_isSubcomponentOf",
             "Range": "DM_Obs_BloodPressure" } },
           {
           "IRI":"DM_Obs_DiastolicBloodPressure",
           "Relationship": {
             "IRI"="RM_isSubcomponenttOf",
             "Range": "DM_Obs_BloodPressure" } }]}

And because ‘is component of ’ had an inverse property axiom which states the inverse property of ‘has component’, the following is automatically calculated:

 {Entity:[{
          "IRI": "DM_Obs_BloodPressure",
         "Relationship": [{
             "IRI"="RM_hasSubcomponent",
             "Range": "DM_Obs_SystolicBloodPressure" },
             { 
             "IRI"="RM_hasSubcomponent",
             "Range": "DM_Obs_Diastolic_BloodPressure" } }]}

Within the ontology the “Blood pressure” observation has a display algorithm property used to indicate that a blood pressure has a special way of being displayed.

Consequently the business logic can rely on the concept of blood pressure in the type property to display the blood pressure’s two parts in a special way e.g. 120/80.

 

 

 

)