Publication Build: This will be filled in by the publication tooling

Profile Hierarchy

These maps are published as entries in the StructureDefinition mapping property, so they are Profiles on existing assets. We considered two other options for documenting maps in FHIR IGs.

1. Creating StructureMap resources to map elements from one object to another. StructureMap supports the transform operation, so this was an appealing possibility. However, extant implementations of that operation presume that both source and target are addressable by FHIRPath. If a standard transformation of Fileman names to FHIRPath can be adopted, this would be an optimal solution.
2. Creating ConceptMap resources to map elements from one object to another. ConceptMap is designed to map concepts (terms), not elements, but the V2-to-FHIR program has extended this resource to support structural mappings. The more predictable structure of V2 assets makes this a bit easier to do. We also were unclear on the value of this approach, which would require more effort than the .mapping approach. Where they exist, our profiles extend US Core R5 profiles, which in turn extend FHIR Core R4 resources. Where no US Core profile is provided, we profile the core FHIR resources. This results in a 2- or 3-level inheritance structure.

The Patient profile illustrates a simple case:

---
title: "class Figure 1: Simple Profile"
config:
    class:
      hideEmptyMembersBox: true
---
classDiagram
    direction LR
    class a["FHIR Core R4 Patient"]
    class b["US Core R5 Patient Profile"]
    class c["VA Patient"]
    a <|-- b
    b <|-- c

In some cases, US Core has provided multiple profiles on a single resource. In these cases, we follow the US Core lead:

---
title: "class Figure 2: Complex Profile"
config:
    class:
      hideEmptyMembersBox: true
---
classDiagram
    direction LR
    class a["FHIR Core R4 Condition"]
    class b1["US Core R5 Condition<br/>Problems and Health Concerns Profile"]
    class b2["US Core R5 Condition<br/>Encounter Diagnosis Profile"]
    class c1["VA Condition:<br/>Problem"]
    class c2["VA Condition:<br/>Encounter Diagnosis"]
    a <|-- b1
    b1 <|-- c1
    a <|-- b2
    b2 <|-- c2

In this case, US Core provides a profile for persistent or chronic problems you might find on a problem list as well as a profile for recording encounter diagnoses. VistA also persists these facts in different ways, so the profiles work well.

In other cases, the VistA data is far more complex than the profile assets provided by US Core. In these cases, we may publish several profiles on a single US Core profile, often with intermediate “abstract” profiles. Lab is one example of this (figure for illustrative purposes is not complete):

---
title: "class Figure 3: Very Complex Profile"
config:
    class:
      hideEmptyMembersBox: true
---
classDiagram
    direction TB
    class a["FHIR Core R4 Observation"]
    class b["US Core R5 Laboratory Result Observation Profile"]
    class c["VA Lab Observation"]
    class d1["VA Lab Observation:<br/>Mirobiology Observation"]
    class d2["VA Lab Observation:<br/>Cytopathology Observation"]
    class d3["VA Lab Observation:<br/>Chem, hem, tox, ria, ser Observation"]
    class e1["VA Lab Observation:<br/>Bacteriology Observation"]
    class e2["VA Lab Observation:<br/>Mycology Observation"]
    a <|-- b
    b <|-- c
    c <|-- d1
    c <|-- d2
    c <|-- d3
    d1 <|-- e1
    d1 <|-- e2

These profiles also instantiate other kinds of relationships via references. These relationships are illustrated on the respective profile pages.