FHIR Model Bundling for UI Generation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing methods for generating user interfaces from Fast Healthcare Interoperability Resources (FHIR) data are inefficient, requiring multiple requests to FHIR endpoints and lacking support for tree structured data, which increases computational resources and network traffic.
Innovation Solution
The FHIR model generates user interfaces by requesting and binding FHIR data into UI control formats, supporting context binding, list binding, and tree binding, and reducing endpoint requests through bundled requests, optimizing resource usage and reducing computational load.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If multiple requests are made to FHIR endpoints to generate user interfaces, then complete data can be retrieved, but network traffic and computational resources increase
Solution Approach 1:
The patent combines multiple FHIR endpoint requests into a single bundled request that retrieves all necessary data (Patient, Observation, and Condition resources) in one network call. This merging of requests reduces network traffic while maintaining data completeness, directly resolving the contradiction between reliable data retrieval and energy loss from network communication.
2Reliability
If multiple requests are made to FHIR endpoints, then all required data is obtained, but processor cycles and memory usage increase
Solution Approach 1:
The system merges multiple data retrieval operations into a single bundled request response, reducing the number of processing cycles required for sequential request handling. The FHIR model processes all required data (Patient, Observation, Condition) from one bundled response, minimizing processor overhead while ensuring complete data retrieval.
3Ease of operation
If traditional OData methods are used to generate UIs, then UI functionality is achieved, but the process lacks efficiency and supports no tree structured data
Solution Approach 1:
The patent changes the data binding parameters from traditional OData flat structures to FHIR-based tree-structured data models. This parameter change enables the system to natively support hierarchical data relationships (Patient-Observation-Condition trees) while improving UI generation efficiency through the optimized FHIR model that reduces network and processing overhead.
4Ease of operation
If FHIR data is bound directly to UI controls without optimization, then data display is achieved, but computational load increases
Solution Approach 1:
The FHIR model acts as an intermediary layer between the FHIR data source and UI controls. This mediator optimizes the data binding process by pre-processing and structuring FHIR bundled responses into UI-ready formats, reducing the computational load on the UI rendering system while maintaining full data binding capability.
Data Source
AI summary
An application file defines a first data object that identifies a fast healthcare interoperability resources (FHIR) server and a second data object that identifies a data type associated with the FHIR server. Based on the first data object and the second data object, a FHIR model requests data of the data type from the FHIR server. The FHIR server provides the requested data, which is received by the FHIR model. Based on the received data, the FHIR model generates data in a user interface (UI) control format and provides the generated data to a UI module that causes a UI to be presented. The FHIR model supports binding of complete entities such as patients or organizations to a UI. This binding enables the requesting of whole entities from a FHIR endpoint, provision of the entity data to the UI, and updating the FHIR data.