We will cover:

• Integration Strategies
• Challenges
• System Architecture
• Demo
• Lessons Learned

• Point-to-Point: Direct links between systems. Simple at first, but scales poorly.
• Integration Platform: Centralized middleware (ESB/iPaaS) manages routing, transformation, and protocol bridging.
• Hybrid: Mix of point-to-point, platform, and legacy strategies depending on the use case and system maturity.

• API-based: RESTful FHIR APIs expose clinical and administrative data using standardized resources.
• Polling: Clients periodically query the FHIR server to check for new or updated data.
• Event-driven: Systems react to specific actions in other systems (e.g., a new Observation), using notifications or messaging queues.
• Subscription-based: Clients subscribe to changes on resources. The FHIR server pushes updates via channels like REST hooks or WebSockets.

• CDS Hooks: Integrates clinical decision support services into EHR workflows.

• Custom Middleware App: Acts as a bridge between our internal EHR and the external FHIR server.
• API-based Access: All data exchange follows the RESTful FHIR standard.
• Manual Trigger: The request to check for data is typically initiated when the physician opens the app.

1. Learning the standard, services, tools, and libraries to work with FHIR.
2. Managing codification systems to comply with the SurPass IG.
3. Managing pseudo-anonymization and re-identification.
4. Securing the system.
5. Testing the system properly.

Dealing with FHIR wasn't the biggest challenge. Nowadays, there are many resources available online, and the official documentation is quite good.

We addressed this problem using a mixed approach. On the one hand, we added some necessary codifications directly within the Genes system. On the other hand, we mapped Genes' internal keys to standard codification systems using our application.

The application checks these codes and essentially acts as a conversion table.

To handle this, our middleware is responsible for encrypting and hashing certain internal business identifiers.

We adopted a security-by-design and multi-layered approach for developing the application. This includes data logging encryption, UI-API communication encryption, HTTPS, and a reverse proxy for external data transmission, following the instructions of the workpackage 3.4, privacy Impact Assessments (“PIAs”) and GDPR compliance.

We initially used JUnit and later transitioned to JSON schemas for validating FHIR resources. We also developed a custom testing framework to test the FHIR API using synthetic data.

1. Must transfer the maximum number of variables possible to elaborate the SurPass.
2. Must be easy to develop.
3. Must use the Genes app infrastructure.

Now we are going to see some schemas following the C4 model by Simon Brown.

These kinds of schemas are flexible and let us show you the general architecture.

Now, we'll see a demonstration of the application.

This video provides a walkthrough of the application in action.

Here are some screenshots showcasing the application's interface.

At this point the application is capable of sending data and retrieving the care plan in addition to the Survival passport.

Import data from the db

Display the data for review

Send the data to the Cineca platform

Retrieve Passport and Care plan

The legacy application, where we can find our data.

The middleware, extract data, transform and interact with FHIR SurPass Server.

• It is easy to work with FHIR.
• The final middleware is tightly coupled to the Genes system, perhaps too much.
• It is not easy to scale or transfer to other systems, so we will explore other solutions for future projects.
• Managing codification systems and testing is challenging.
• We are not particularly proficient in the agile working style and need to improve.