Pan-Canadian Health Data Content Framework — Logical Data Model Version 2, September 2025

I’ve built a visual representation of all the LDM entities. The scale is becoming a concern, and is most clearly seen visually.

Each additional layer of granularity increases the implementation burden on developers trying to conform to the standard. I see people have already raised the idea of collapsing certain entities, and I think that direction is necessary.

A closer data modeling to align with FHIR would strengthen interoperability. I’ve mapped the LDM resources against FHIR and prepared a demo of how that alignment could work.

I appreciate the direction the LDM is heading, but the current level of complexity places a significant load on anyone trying to implement it. With the additional A more streamlined structure would make adoption far more realistic.


Feel free to reach out, happy to demo my work on this.
-James McCormack, CEO @ XPawn

# Feedback: CIHI LDM Entity Structure Analysis

## Executive Summary

As part of mapping CA Core Data for Interoperability (CACDI) to the CIHI Logical Data Model (LDM), we analyzed all 245 entities in the CIHI LDM to identify opportunities for structural simplification. This analysis identified **87 entities (35%)** that could potentially be collapsed or consolidated, which would reduce complexity while maintaining data integrity and relationships.

## Proposed Collapsing Strategy

### Strategy 1: Collapse Entities with Zero or One Attribute

Entities with minimal attributes are good candidates for collapsing into parent entities:

- **56 zero-attribute entities**: These are pure junction/relationship entities that only connect other entities (e.g., "Account", "Activity Location", "Animal", "Device"). These can be represented as relationships in parent entities rather than separate entities.

- **31 single-attribute entities**: Simple attribute entities that can be represented as attributes of parent entities (e.g., "Person Death", "Person Gender Used", "Health Care Provider Type"). These maintain the same information but simplify the structure.

### Strategy 2: Consolidate Event Entities

**17 Event entities** with 0-1 attributes will be consolidated into a **single unified Event entity**:

- Administrative Event
- Adverse Event
- Assessment Event
- Clinical Event
- Clinical Test Event
- Education Event
- Health Care Service Event Non-Patient Participant
- Health Care Service Event Patient Health Concern
- Health Event
- Immunization Event
- Intervention Event
- Lab Test Event
- Medical Imaging Event
- Periprocedure Event
- Public Health Event
- Requisition Event
- Specimen Imaging Event

**Implementation**: Create a single `Event` entity with an `Event Type Code` attribute to distinguish event types. This preserves all type information while reducing complexity from 17 separate entities to 1 unified entity.

## Impact Analysis

### Current State

- **245 total entities** in CIHI LDM
- Each entity requires separate representation and mapping

### Proposed State

- **~158 entities** would remain as separate entities
- **87 entities collapsed** (35% reduction)
- **1 unified Event entity** instead of 17 separate event types

### Benefits

1. **Reduced Complexity**: 87 fewer entities to represent and maintain
2. **Simplified Mappings**: Direct attribute mappings instead of nested entity relationships
3. **Unified Event Handling**: Single Event entity with type code is cleaner and more maintainable
4. **Maintained Data Integrity**: All information preserved through attributes and type codes
5. **Improved Maintainability**: Fewer entities to manage and update
6. **Better Alignment with CACDI**: Simplified structure aligns better with CACDI data elements

## Entities Recommended to Keep Separate

The following **78 entities** should remain as separate entities due to:

- Multiple parent references (>2 parents)
- Complex relationships (>3 relationships)
- Multiple attributes with complex structure
- Support for multiple values per parent (e.g., Person Name, Person Gender Identity, Address, Contact Mechanism, Patient Health Identifier)

## Rationale

### Why Collapse Zero-Attribute Entities?

Junction/relationship entities with no attributes serve only to connect other entities. Representing these as relationships in parent entities is more efficient and reduces unnecessary complexity. These entities don't carry any data themselves - they only represent associations between other entities.

### Why Consolidate Event Entities?

Event entities share common attributes (dates, status, participants, location) and differ primarily by type. A unified Event entity with a type code:

- Reduces duplication of common attributes across 17 entities
- Simplifies mapping and data exchange
- Maintains all type information through the type code
- Reduces maintenance burden when common event attributes change
- Aligns with common data modeling patterns for polymorphic concepts

### Why Keep Some Entities Separate?

Entities with multiple parents, complex structures, or support for multiple values per parent need to remain separate to:

- Preserve referential integrity
- Support complex relationships
- Handle multi-value scenarios correctly
- Maintain data model flexibility

## Examples

### Example 1: Person Death (Collapse)

- **Current**: Separate "Person Death" entity with 1 attribute
- **Proposed**: Attribute of "Person" entity
- **Rationale**: Single value per person, simple structure

### Example 2: Event Entities (Consolidate)

- **Current**: 17 separate Event entities (Administrative Event, Adverse Event, etc.)
- **Proposed**: Single "Event" entity with "Event Type Code"
- **Rationale**: Common structure, differ only by type

### Example 3: Person Name (Keep Separate)

- **Current**: Separate "Person Name" entity
- **Proposed**: Keep as separate entity
- **Rationale**: Multiple names per person, complex structure with effective/expiry dates

## Questions for CIHI Review

1. **Event Consolidation**: Does consolidating 17 Event entities into 1 unified Event entity with type code align with CIHI's data model vision?

2. **Zero-Attribute Entities**: Are there any zero-attribute entities that should remain separate for business reasons, even though they have no attributes?

3. **Single-Attribute Entities**: Are there any single-attribute entities that should remain separate due to future expansion plans or business requirements?

4. **Multi-Value Support**: For entities like Person Gender Identity, Person Indigenous Identity, etc. that support multiple values, should these remain separate or be handled differently?

5. **Implementation Impact**: Would this collapsing strategy impact any data exchange requirements?

## Recommendation

We recommend considering this collapsing strategy as it:

- Significantly reduces model complexity (35% reduction)
- Maintains all data and relationships
- Improves maintainability and clarity
- Preserves flexibility for complex entities
- Better aligns with CACDI data element structure

The strategy could be implemented incrementally, starting with zero-attribute entities and Event consolidation, which have the highest impact and lowest risk to existing implementations.

EPIC should be Epic, I think

Recommend adding "(e.g., DICOM UID)"

Could you add normalization guidance for phone and email formats (E.164, RFC 5322) and FHIR ContactPoint.system/use mappings for consistent communication data?

Doesn't have to be a strict business rule - that would likely be difficult to enforce

extra 'v'

When updated, consider a state transition diagram or table for Appointment (requested → booked → fulfilled → canceled) and align these with FHIR Appointment.status and Slot.status values.

Could you consolidate “reported” and “actual” procedures and immunizations into a single Procedure and Immunization table respectively with a source-of-truth attribute, then expose business views for each to simplify ETL processes?

To reasonably represent these in FHIR each of these would need to be a set code for the type of SDOH (e.g. employment status) and a valueset of possible answers.

How should implementers technically enforce the Mandatory: XOR(Immunization Event, Reported Immunization) constraint in relational databases, which typically requires a custom check constraint, to ensure this critical business rule is maintained at the data layer?

Do not make an item without a valueset No Absent.

For the Patient Health Identifier, the unique key includes Patient Health Identifier, Patient Health Identifier System, and Patient Health Identifier Effective Date; can the model clarify the policy and business rule that necessitates including the Effective Date as part of the unique business key?

To ease the burden of database mapping, we suggest providing an additional set of documentation that details the recommended implementation strategy for the Party entity’s generalization hierarchy (Party --> Person, Party --> Organization) in a relational database.

Or flattening this structure

Guidance if any is available for which value set to use when for all multi-valueset would be helpful

The use of Generalization (subtyping) is a core object-oriented concept that aids conceptual clarity (e.g., Substance is a Drug ). However, for performance and simplicity in an RDBMS, this is often "flattened" into a single table with discriminator columns, which introduces complexity for developers and requires clear mapping documentation beyond the logical model.

Is this meant to be object oriented or a database model?

Person could be collapsed into a single entity. Many child entities of Person could be collapsed into attributes.

Person could be collapsed into a single entity. Many child entities of Person could be collapsed into attributes.

Why is AI modelled? It's a tool like any other decision support system.

Recommend linking to a normative version to aligning to commonly used R4 version links. for all HL7 value sets, unless specifically recommending a general or most up to date version.

Specimen is also referenced in DI, is that only as it relates to Digital Pathology?

Do these incidents share any common data elements? Should there be a parent incident type?

Unclear on Party Role purpose when unique entities exist for all Party Roles.

Why define the general Observation component and observations which have components?

Should only the measurements and specific data elements and codes be defined?

What is the purpose of this document reference data element?

Why has the language changed from "is/has" to be more expansive and outside the scope of what an Entity Relationship diagram is supposed to convey? E.g. "plays," "about," are not logical terms

Are these maturity levels on the diagram? It would be helpful to have them there.

It's clear who the data model is for, but it's not clear how one uses the data model. Do we stand up a database which has the data from the LDM? Is it a helpful reference for what should be stored? Can we use it to help establish contracts between systems?