[%settitle Logical Models%] [%file newheader%] [%file newnavbar%]

Logical models

A Logical data model or logical model is a representation of data structures, that is not necessarily based on or implemented in a FHIR implementation. Logical models contain data elements (entities and attributes) and their constraints and relationships. They allows data requirements to be described from a functional perspective, without attaching to a specific implementation or technology.

A FHIR logical data model - or simply logical model - is an expression of a data structure captured using FHIR. (There are other formats for representing logical models: visual models (such as UML diagrams), and proprietary formats, such as Sparx Enterprise Architect or others.)

Although FHIR logical models use FHIR for their representation, this does not imply that the logical models represent or are attached to FHIR resources. Logical models are abstract data structures, normally defined for a given purpose, which can be instantiated into one or more "physical" FHIR resources (or profiles) to be implemented in data exchange. But they can also be implemented in other standards.

Defining logical models

A logical model is defined in FHIR as a StructureDefinition which is a specialization of a base type (Element or Base) where StructureDefinition.kind = logical.

For example,

  "kind": "logical",
  "abstract": false,
  "baseDefinition": "http://hl7.org/fhir/StructureDefinition/Element",
  "derivation": "specialization",

• A base type of Element contains id and extension and the ele-1 constraint (All FHIR elements must have a @value or children). Authors can decide which is best.- The baseDefinition type can also be another absolute URL (another logical model). This allows reusing logical models for example to support variations.
• For logical models, setting abstract to true or false has no predefined impact - authors can define it based on their goals for the model.

Content of logical models

Logical models are expressed in FHIR with StructureDefinition with ElementDefinitions.

The StructureDefinition defines:

• metadata - title, status, authorship, purpose, etc.
• Base of the structure (Base, Element, or another logical model)

ElementDefinition capture the actual data elements that constitute the structure. ElementDefinitions in a logical model typically contain:

• Name and definition: These are context-specific definitions of the element, regardless of whether they correspond to a given FHIR element
• Cardinality - the functional, intended cardinality of the element within the logical model
• Type - if the logical model intends to define types
• Binding - for coded elements, it is possible - but not mandatory - to define some terminology binding
• Example content (for illustrative purposes)

Datatypes in logical models

Elements in a logical model are expected to have a type because of how FHIR structures are defined. It is posible to use the FHIR datatypes, although this brings "physical" constraints, formats, etc. into abstract logical data models which might not be intended. For example, a logical model may need to define a date, regardless of the "physical" format of the date being DDMMYY, DDMMYYYY or MM-DD-YYYY.

It is possible to define datatypes for use in logical models, by profiling the existing types in FHIR. However, redefining the FHIR primitive datatypes is not supported.

Terminology bindings

Logical models may contain bindings for coded elements, and the corresponding binding strength. This can be used to capture the "intended" or "business / functional" requirements on data elements, independently of any actual coding system. It may also be used to impose terminology constraints on a functional level, if they are meaningful at that level. For example, on a functional level, it is possible to impose code systems like state codes, or country codes (ISO 3166-2), or to legal codes for marital status - as these are not only technically relevant for a given system, they are imposed (typically by norms or regulations) at a business level. Such specifications can be persisted in logical models, and thic can be used to impose that any technology implementation that follows the logical model shall consider the terminology binding.

Using logical models

Functional data modeling

FHIR logical models are typically used to capture the functional data requirements for an implementation. For example, analysts can use logical models to determine and agree upon the functional data needs as above - attributes, structure, datatypes, cardinalities, relationships, terminologies, etc. without introducing techical constraints on the data structure or considering the actual FHIR resources in a specific version. Projects and organizations can use and publish logical models to define their "data dictionaries" - a compilation of data elements - as the semantic definitions and expectations for a given purpose. Logical models are normally intended to be designed (and validated) on a functional level, independently of technical implementation. As business/functional analysts design the data needs, technical implementers can implement logical models by projecting them onto a physical implementation - typically as one or several FHIR resources (including extensions). The implementation can also be in other standards such as HL7 V2, CDA, SPL, or GS1 XML, etc.

Patterns

FHIR logical models can be used to capture design patterns for data structures which may then be implemented in FHIR resources. This FHIR specification uses logical models to capture design patterns that are expected the FHIR resources representing requests, events, etc..

Crosswalk / Mapping between FHIR versions or different standards

Logical models can be used as a common abstraction that serves as a pivot point between different technical specifications. This can be used to map between different specifications - like FHIR versions.

Related standards and implementations

Standard terminologies

Logical models can map to conceptual terminologies such as SNOMED CT, in different ways:

• in some cases, the concept represented by the model can correspond to a standard concept
  • e.g., "Patient" --> SCT#116154003;
• some elements in the model may correspond to standard concepts
  • e.g., "Gender identity" = SCT#33821000087103;
• or the actual values allowed for the data element may correspond to standard concepts;
  • e.g., "Identifies as male gender (finding)" = SCT#446151000124109 ;

[%file newfooter%]