Bonus Article #4: Understanding the FHIR Patient Resource with a Focus on Identifiers, CodeableConcept, Flags, and Cardinality

FHIR (Fast Healthcare Interoperability Resources) is an essential standard for healthcare data exchange, and the Patient resource is one of the most widely used resources in the standard. It serves as the foundation for managing demographic and administrative data about individuals receiving healthcare. This article delves deep into the Patient resource, with a special emphasis on identifiers, CodeableConcept, flags, and cardinality, while providing practical examples and use cases to illustrate their importance.

What is the Patient Resource?

The Patient resource is a representation of a person who is receiving or may receive healthcare services. It captures critical demographic details such as name, date of birth, gender, address, contact information, and administrative data like medical record numbers and national identifiers. It is the backbone for most healthcare systems and interoperability workflows, connecting multiple domains like billing, clinical care, and insurance.

Key Elements of the Patient Resource

1. Identifiers

Identifiers are critical for uniquely identifying a patient within specific contexts or systems. They ensure that patient data can be accurately retrieved and linked across multiple healthcare systems or organizations.

Structure of an Identifier

• Use: The purpose of the identifier, such as official (primary record) or temp (temporary use).
• Type: Describes what kind of identifier it is using a CodeableConcept, such as MR (Medical Record Number) or SSN (Social Security Number).
• System: Specifies the namespace or organization issuing the identifier, such as a hospital’s internal system or a national healthcare registry.
• Value: The actual identifier, like the medical record number or national ID.
• Period: The time period during which the identifier is valid.

Example

A patient might have identifiers for different systems:

"identifier": [
  {
    "use": "official",
    "type": {
      "coding": [
        {
          "system": "https://terminology.hl7.org/CodeSystem/v2-0203",
          "code": "MR",
          "display": "Medical Record Number"
        }
      ]
    },
    "system": "https://hospital-a.org/mrn",
    "value": "A123456",
    "period": {
      "start": "2015-06-01"
    }
  },
  {
    "use": "official",
    "type": {
      "coding": [ 
       {
          "system": "https://terminology.hl7.org/CodeSystem/v2-0203",
          "code": "MR",
          "display": "Medical Record Number"
        }
      ]
    },
    "system": "https://hospital-b.org/mrn",
    "value": "B789101",
    "period": {
      "start": "2018-01-01"
    }
  }
]        

Use Case: A Patient with Multiple Identifiers

Consider a patient who has received care at two different hospitals:

• Hospital A issues an identifier (A123456) used for internal medical records.
• Hospital B issues a separate identifier (B789101).
• The patient’s insurance provider assigns a unique ID for claim processing.
• If these identifiers are stored in the Patient resource, systems can reconcile data across hospitals, ensuring a complete view of the patient’s healthcare history.

2. CodeableConcept

The CodeableConcept data type provides a standardized way to represent codes while also including human-readable text. This flexibility is crucial for ensuring both machine-readability and human interpretability.

Structure of a CodeableConcept

• Coding: A list of codes from one or more coding systems (e.g., SNOMED CT, LOINC).
• Text: A plain-text description of the concept.

Example

For marital status:

"maritalStatus": {
  "coding": [
    {
      "system": "https://terminology.hl7.org/CodeSystem/v3-MaritalStatus",
      "code": "M",
      "display": "Married"
    }
  ],
  "text": "Married"
}        

Use Case: CodeableConcept in Action

Imagine a scenario where a patient’s marital status is represented as "M" in one system (coded), while another system only processes textual descriptions like "Married." CodeableConcept ensures both systems can understand the data.

3. Flags

Flags are Boolean attributes or properties that indicate specific conditions or states about the patient. They provide high-level information and help systems make quick decisions.

Common Flags in the Patient Resource

• Active: Indicates if the patient record is currently active (true) or inactive (false).
• DeceasedBoolean: Specifies if the patient is deceased (true or false).
• DeceasedDateTime: Provides the exact date and time of death if applicable.

Example

"active": true,
"deceasedBoolean": false        

Use Case: Flags in Action

A health information exchange (HIE) system can use the active flag to exclude inactive patient records from being returned during queries, reducing unnecessary data processing.

4. Cardinality

Cardinality defines how many times an element can appear in a resource. It ensures data consistency and specifies whether an element is optional, required, or can repeat.

Key Cardinality Values

• 0..1: The element is optional and can appear at most once.
• 1..1: The element is required and must appear exactly once.
• 0..*: The element is optional and can appear multiple times.
• 1..*: The element is required and must appear at least once.

Examples in the Patient Resource

• Name (0..*): A patient can have multiple names, such as a legal name and a maiden name.
• Gender (0..1): Gender is optional but can only have one value if present.
• Identifier (0..*): A patient can have multiple identifiers, such as IDs from different healthcare systems.

Use Case: Multiple Names

For a patient with both a maiden name and a legal name:

"name": [
  {
    "use": "official",
    "family": "Smith",
    "given": ["Jane"]
  },
  {
    "use": "maiden",
    "family": "Doe",
    "given": ["Jane"]
  }
]        

Comprehensive Example of a Patient Resource

{
  "resourceType": "Patient",
  "id": "example",
  "identifier": [
    {
      "use": "official",
      "type": {
        "coding": [
          {
            "system": "https://terminology.hl7.org/CodeSystem/v2-0203",
            "code": "MR",
            "display": "Medical Record Number"
          }
        ]
      },
      "system": "https://hospital-a.org/mrn",
      "value": "A123456",
      "period": {
        "start": "2015-06-01"
      }
    }
  ],
  "active": true,
  "name": [
    {
      "use": "official",
      "family": "Smith",
      "given": ["John", "Andrew"]
    }
  ],
  "gender": "male",
  "birthDate": "1980-01-01",
  "maritalStatus": {
    "coding": [
      {
        "system": "https://terminology.hl7.org/CodeSystem/v3-MaritalStatus",
        "code": "M",
        "display": "Married"
      }
    ],
    "text": "Married"
  },
  "deceasedBoolean": false
}        

Here is a detailed explanation of each system field in the provided FHIR Patient resource, explaining its purpose and context:

Identifier: system

Field:

"system": "https://hospital.org/mrn"        

Explanation:

• The system field in an identifier represents the namespace or issuing authority that governs the identifier. In this case, the system is https://hospital.org/mrn, which is likely the URL or URI of the hospital's Medical Record Number (MRN) management system.
• It helps distinguish identifiers issued by different organizations or systems. For example, a patient may have a medical record number from multiple hospitals, each associated with a different system.

Example Use Case:

A patient receives care at two hospitals:

• Hospital A issues an identifier under the system https://hospitalA.org/mrn.
• Hospital B issues a different identifier under https://hospitalB.org/mrn.

When querying or exchanging data, the system ensures the identifier’s context is clear, avoiding confusion between the two hospitals' identifiers.

Type Coding: system

Field:

"system": "https://terminology.hl7.org/CodeSystem/v2-0203"        

Explanation:

• This system is part of the coding element in the type field of the identifier. It references an HL7-defined code system (v2-0203), which standardizes identifier types across healthcare.
• The specific code in this system (MR) denotes a Medical Record Number.

Use Case:

The system ensures that the type of identifier is unambiguous. For example:

• A code of MR under the HL7 v2-0203 code system universally indicates a Medical Record Number.
• This allows systems using different terminologies to interpret and map identifiers correctly.

Context of Use:

HL7 v2-0203 is a widely recognized code system in healthcare IT, making it suitable for interoperability between systems.

Marital Status Coding: system

Field:

"system": "https://terminology.hl7.org/CodeSystem/v3-MaritalStatus"        

Explanation:

• This system is part of the coding element in the maritalStatus field, referencing the HL7 v3 code system for marital status.
• It defines a standardized list of marital statuses, such as M (Married), S (Single), or D (Divorced).

Example Use Case:

Two systems exchange patient data:

• System A records marital status as M under the HL7 v3 code system.
• System B, using the same code system, interprets M as "Married," ensuring consistent understanding between the systems.

Importance:

Using a standardized system ensures that the marital status is interpreted correctly, regardless of language or local conventions.

General Significance of system Fields

The system field is critical in FHIR for several reasons:

General Significance of system Fields

The system field is critical in FHIR for several reasons:

• Namespace Identification:

It provides a unique context for the value of a field. For example, two hospitals may both use the value 123456 for a Medical Record Number, but the system differentiates them.

• Interoperability:

Systems exchanging FHIR data can map and interpret fields correctly if the system is known and standardized.

• Standardization and Clarity:

By referencing global standards like HL7 code systems, the system ensures that the meaning of coded values (like MR or M) is unambiguous.

• Avoiding Collisions:

The same value can appear in different contexts (e.g., different hospitals or identifiers), but the system guarantees they remain distinct.

Contextual Summary for Each Field

• Identifier system:

Links the identifier to the issuing organization (e.g., a hospital’s MRN system).

Provides context for the identifier value (123456).

• Type Coding system:

Defines the type of identifier using a global standard (HL7 v2-0203).

Ensures the code (MR) is interpreted universally as a Medical Record Number.

• Marital Status Coding system:

Uses the HL7 v3 code system to represent marital status consistently.

Ensures that the code (M) and display value (Married) are understood across systems.

By incorporating these system fields, the resource adheres to FHIR’s goal of enabling seamless and accurate interoperability in healthcare.

Key Takeaways

1. Identifiers ensure unique representation of patients across systems, enabling reliable interoperability.
2. CodeableConcept balances standardization and human readability, critical for complex healthcare systems.
3. Flags provide quick insights about the patient’s status and help systems filter data effectively.
4. Cardinality defines rules for how many times an element can appear, ensuring structured and consistent data.

By mastering these concepts, you will be able to confidently work with the Patient resource and apply similar principles to other FHIR resources.