FHIR Modeling: Removing CDA Qualifiers For Better FHIR Integration

Welcome, everyone! Today, we're diving into the world of FHIR (Fast Healthcare Interoperability Resources) and how we can refine our modeling efforts by moving away from certain CDA (Clinical Document Architecture) constructs. Specifically, we'll be discussing the removal of "qualifier" profiles and extensions, which, while useful in the context of CDA, don't quite align with the core principles and flexibility of FHIR. This shift aims to create a more streamlined and intuitive approach to healthcare data exchange.

The Problem with CDA Qualifiers in FHIR

Let's start by understanding the problem. The "qualifier" extension, often used in CDA documents, doesn't have a direct equivalent in FHIR. It's more of a technical workaround to mimic certain CDA functionalities. This can lead to a less-than-ideal FHIR implementation. In FHIR, we strive for clarity, reusability, and a data model that reflects real-world clinical scenarios. Using CDA-inspired qualifiers can sometimes muddy the waters, making it harder to leverage the full potential of FHIR. This is where this article comes into play.

Our primary goal here is to enhance the FHIR data model, allowing for more precise and effective data representation. CDA, on the other hand, is a standard focused on document exchange, and its structure often prioritizes document-centric views. While CDA has its place, particularly in legacy systems, FHIR is designed for a different purpose: enabling interoperability at the data level. We are going to replace the qualifier extension in the FHIR structure with more suitable FHIR attributes. This approach allows us to represent clinical concepts more directly, enhancing the overall quality and efficiency of healthcare information exchange. Think of it as upgrading your data exchange capabilities to better utilize the features and flexibility inherent in FHIR.

We'll be exploring a step-by-step methodology to identify and replace these qualifiers. This involves examining where qualifiers are currently used within our existing FHIR profiles and determining how to best integrate them, or how we may replace them with built-in FHIR attributes to get the best result.

Methodology: Replacing Qualifiers with FHIR Attributes

So, how do we tackle this transition? Here's a practical approach:

1. Identify the Use Cases: Begin by listing all the FHIR attributes that currently rely on qualifiers. We will start the process by examining the current implementation, which relies heavily on qualifiers to understand the underlying data accurately. By creating a comprehensive list, we can create a clear picture of every instance the qualifiers are used. This includes profiles such as FREncounterEventDocument, FRImmunizationRecommendationDocument, FRImmunizationDocument, FRObservationLaboratoryReportResultsDocument, FRMedicationDocument, FRObservationSocialHistoryDocument, FRObservationStatusDocument, and FRObservationSurveyDocument. Having this list will be the first step in replacing qualifiers with more accurate and specific FHIR attributes.

2. Assess FHIR Attributes: For each item on the list, carefully examine available FHIR attributes. We're looking for existing attributes that can adequately replace the function of the qualifier. For instance, consider Patient.name.use. The use attribute might elegantly and effectively express the intent behind the qualifier, removing the need for an extension.

3. Create FHIR Extensions (If Necessary): In some cases, existing FHIR attributes may not be a perfect fit. If no standard FHIR attribute is suitable, consider creating custom extensions. These extensions should be designed to maintain consistency, interoperability, and the overall integrity of the FHIR data model. By carefully evaluating each use case, we aim to strike a balance between leveraging existing FHIR resources and, when absolutely needed, creating tailored solutions. Careful implementation ensures a future-proof, robust approach to FHIR modeling.

By following this method, we systematically remove the reliance on qualifiers, thus helping to streamline your FHIR implementation.

Files to be Removed

As we work through this process, the following files will likely be removed from our implementation:

• input/fsh/RessourcesFHIRCorps/dataType/FRCodeableConceptDocument.fsh
• input/fsh/RessourcesFHIRCorps/dataType/FRCodingDocument.fsh
• input/fsh/RessourcesFHIRCorps/extensions/FRQualifierExtension.fsh

These files, which provide the definition and structure of the now-deprecated qualifiers, will be safely retired, decluttering the implementation and minimizing the potential for future confusion or misunderstanding of the data model.

Profiles Utilizing Qualifiers

We will examine the profiles, listed below, which currently employ these qualifiers. This is where the bulk of the work will take place. We'll assess how each profile can be adjusted, using existing FHIR attributes or extensions to ensure accurate and appropriate representation of the information.

• FREncounterEventDocument
• FRImmunizationRecommendationDocument
• FRImmunizationDocument
• FRObservationLaboratoryReportResultsDocument
• FRMedicationDocument
• FRObservationSocialHistoryDocument
• FRObservationStatusDocument
• FRObservationSurveyDocument

The goal is to update these profiles to leverage standard FHIR attributes or create custom extensions where needed. This will lead to a more maintainable, interoperable, and standardized data model, providing better data exchange overall.

Collaboration and Discussion

This project will undoubtedly involve collaboration and discussion. Key stakeholders, such as @souadbenmustapha and @Monstermanu, are already involved. Their expertise and insights are valuable as we transition. We welcome suggestions, questions, and feedback from the broader community as we build and refine our FHIR implementations.

We encourage discussion, and we are open to exploring novel approaches and seeking community-driven solutions to achieve our goals. The end result? A more integrated, intuitive data model that better suits the modern healthcare landscape.

Conclusion: Moving Towards Better FHIR Modeling

Removing CDA qualifiers from our FHIR implementations is a significant step towards improving interoperability, standardization, and the overall usability of healthcare data. By embracing native FHIR attributes and creating custom extensions when needed, we can build a more robust and adaptable system. This approach not only streamlines our data exchange processes but also ensures that our implementation adheres to the latest best practices in the FHIR standard.

This is not a one-time process; instead, it is an ongoing effort that requires continuous evaluation, feedback, and refinement. Through collaboration and discussion, we can create a sustainable FHIR implementation that supports better patient care and drives innovation in healthcare.

For more information on the FHIR standard, check out the official website: HL7 FHIR