Entity subtype attribute

 Within the ontology, a data model entity may be a subclass of another data model entity, which means that it is a more specialised class than its super entity. The entity will also have a number of business purpose specific attributes which tend to relate to the meaning of the entity but are 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 implementor 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 would be used.

A solution must be found the problem of data model logical entities versus database tables or node types.

Implementors would probably create a few high level tables to which many scores of sub-entities would map.

A question then arises as to how implementors would indicate the data model entity’s sub type so that business logic and query can be sure of entities that must be examined and the attributes they can query.

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 implementors 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 ‘Entity sub Type property’ is defined in the ontology.

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

to the above statements the following could be found in the data model/ schema map.

{  "DataModelEntity":"DM_Encounter",

   "SchemaEntity":"encounter",

    "EntitySubType":{
            "Property":"DM_type",   // The entity sub type field of encounter table is “type”
            "Class":"DM_Encounter"    // the subtype must be a subtype of encounter}},

{"DataModelEntity":"DM_Observation",
        "SchemaEntity":"observation",
         "EntitySubType":{
                       "Property":"DM_type",   // The entity sub type field of observation table is “type”
                        "Class":"DM_Observation"  the type value must be a subtype of observation}

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

This appears to be a self-referencing or reflexive property. However, when used at run time the value uses a concept as a value of the type property:

Table                   Field                    Value

Encounter          type                    Accident and emergency attendance

Observation      type                    Blood pressure

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                                               Attribute                       Range                                Cardinality

Systolic blood pressure                is component of             Blood pressure                0:1

Diastolic blood pressure              is component                  Blood pressure                0:1

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

Entity                                               Attribute                         Range                                Cardinality

Blood pressure                              has component              Systolic blood pressure 0:*

Blood pressure                              has component              Diastolic blood pressure 0:*

 

Within the data model 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.

 

 

 

)