5 Challenges and Solutions of Mapping to FHIR Resources

This article provides an insider’s perspective on a project where we took on the challenge of developing a solution to bridge the gap between our client’s diverse data sources – including CSV files and databases – and the rigorous FHIR standard. Our ultimate goal was to prepare the client’s data for seamless integration into AWS HealthLake, opening up a world of possibilities for research and other healthcare applications.

1. The FHIR Resource Hierarchy

One of the fundamental challenges in converting data into FHIR is the fundamental difference in structure between FHIR resources and traditional data sources, such as CSV files and relational databases. While traditional data sources are typically organized into tables with rows and columns and relationships between them, FHIR resources are represented by a tree-like structure. This tree structure can be multiple levels deep, with some resources referencing other resources, and in some cases, circular dependencies can emerge.

Navigating this intricate tree of resources and data types can be a challenge, especially when dealing with extensive datasets.

To address the complexity of the FHIR resource hierarchy and mitigate the challenges associated with circular dependencies, it is necessary to provide a structure for data import. This approach should allow data to be ingested without unnecessarily digging deep into the complex FHIR tree. This structured import strategy simplifies data analysis and ensures that the process remains manageable.

2. Dynamic Mapping Algorithm

To address these challenges, a user-friendly mapping algorithm was introduced by our team. The primary objective was to provide a dynamic and reusable solution, while avoiding the limitations of hardcoding. This algorithm incorporates a user interface for mapping source data to FHIR resources, with the FHIR resource tree displayed for reference.

Handling Primitive and Data Types

While working with Primitive Types in FHIR is relatively straightforward, Data Types introduce a new layer of complexity. Data Types, such as addresses, are themselves objects and can contain other Data Types. Additionally, some Data Types can be represented as arrays, further complicating the mapping process. For instance, the “HumanName” Data Type includes an array of “Given” values but only one “Family” attribute.

Designing a user interface that accommodates this complexity requires careful consideration, as each child node of the FHIR tree can be either a Data Type or an Array, leading to a more complicated structure.

Having a codebase with all FHIR resources in a handy format of one of the popular programming languages, we were able to write a script that would recursively iterate over this tree analyzing each attribute, its type (Primitive Type, Data Type) its numericality, and generate JSON config for the future FHIR tree. Special attention is given to the handling of circular dependencies, ensuring that the recursive algorithm doesn’t go into infinite loops.

Addressing Circular Dependencies

A critical challenge in mapping to FHIR resources is handling circular dependencies. For instance, the “Extension” type in FHIR can be linked to almost any resource and can also have other extensions within it, potentially resulting in circular references. To address this issue, the mapping algorithm includes additional conditions during analysis. It identifies scenarios where child and parent nodes share the same resource type and excludes them from consideration. While this assumption may not be true in all cases, it proves to be effective in many real-world scenarios.

Dynamic Tree Depth

One size does not fit all when it comes to mapping to FHIR resources. The depth of the FHIR resource tree required for mapping depends on the specific data source and the client’s requirements. Analyzing the client’s data source and aligning it with the FHIR structure is essential to determining the required tree depth. In some cases, a fixed depth may be sufficient, while in other cases, a more dynamic approach may be required to handle varying levels of complexity.

3. User-Friendly UI

In addressing the challenges of mapping data to the FHIR standard, we have developed a user-friendly interface that allows clients to select nested types and corresponding columns from their data source. It is essential to note that some FHIR elements have numericality, which requires not only element mapping but also the specification of element indices. numericality can apply to various data types within FHIR, and identifying which types have numericality greater than 1 means that they represent arrays. This user-friendly interface streamlines the mapping process for the client, making it even more accessible to users with limited technical expertise.

4. Dynamic Values Mapping and Standardized Codes

Once FHIR attribute mapping is complete, the next challenge is value mapping. FHIR enforces strict data typing, meaning that data must adhere to specific codes and required fields. However, in many cases, customer data does not match the predefined values in the FHIR standard. To address this, we have implemented a dynamic mapping mechanism.

This mechanism analyzes all columns provided by the customer in their data source. It identifies unique values within those columns and attempts to map them to the values specified in the FHIR standard. In cases where no direct matches are found, the system identifies sets of unique values and presents them to the client for mapping. For example, variations such as “M”, “m”, “man”, and “Man” could all be mapped to the FHIR standard value “Male”. This dynamic mapping, coupled with thorough data analysis, allows the client to map all values effectively.

Standardized code presents a greater challenge. FHIR mandates the use of strict codes, especially in contexts such as immunizations and allergies. Snomed and Loinc are two standardized code systems that are widely used by users of the FHIR standard. The importance of standardized codes is to ensure that data exchanged between FHIR users is consistently understood. 

To address this, we have added additional modules to our system that allow for convenient code searching. As the number of codes can be extensive, this feature is invaluable. This functionality allows the client to map disease codes, ensuring standardization and accurate disease-related data in FHIR documents, which is critical for subsequent analysis.

5. Optimal Data Storage

During the development of our solution, the question of data storage for intermediate results arose. While a relational database might seem like an obvious choice, a closer look at FHIR types revealed an overwhelming number of types and dependencies. Managing such a database would be nearly impossible. On the other hand, a document-based NoSQL database could be considered, but it became clear that storing intermediate data was not a project requirement.

The key questions that guided our decision were:

• Why do we need to store this data?
• Would there be a need to search it?
• Would this data be displayed?

As a result, we decided not to store intermediate data. Instead, we focused on storing metadata for mapping, an array for mapping data source attributes to FHIR, and the client’s mapping settings. This approach allowed us to run a script at runtime to generate a FHIR document. The elimination of the need to store intermediate data provided flexibility in our code organization. As a result, all objects were built at runtime, eliminating the need for database operations or file storage, which significantly increased processing speed.

Conclusion

Mapping data sources to the FHIR standard presents multifaceted challenges, from navigating complex resource hierarchies to dynamically mapping values and handling standardized code. Innovative solutions, such as our user-friendly mapping algorithms and dynamic mapping mechanisms, play a critical role in overcoming these obstacles. In addition, optimizing data storage strategies by eliminating the need for intermediate data storage can enhance processing speed and code flexibility.

As the demand for healthcare data interoperability continues to grow, the ability to effectively map disparate data sources to the FHIR standard will become increasingly important. By understanding and overcoming the difficulties inherent in this process, organizations can realize the full potential of FHIR for improved healthcare data exchange and analysis, ultimately improving the quality of care and research in the healthcare industry. Such data analytics will play a significant role in the immediate future and is a highly promising direction because standardized data in FHIR format can be examined by various machine learning tools, facilitating the creation of predictions and interdependencies between different factors and diseases. This, in turn, has the potential to identify previously unknown health issues and address them through proactive measures or effective preventative strategies.

• #BI and Big Data
• #DevOps Outsourcing
• #Healthcare
• #Industry Standards Compliance