Healthcare runs on data, but too often, that data doesn't feel like it was designed for the people who use it. Doctors and administrators regularly face cryptic codes when what they really need is a name, an identifier, or a simple confirmation of which hospital is in charge.
This was exactly the challenge we faced with FHIR EpisodeOfCare resources. By default, they tracked patient care episodes using reference codes, but those references weren't very useful in practice. They were difficult to query, slowed down workflows, and created friction in sharing data across organizations.
We set out to fix that by enhancing EpisodeOfCare resources with richer references adding patient identifiers, display names, and organization names directly into the resource. The reason was simple: more detailed references make queries easier, reduce ambiguity, and dramatically improve interoperability, especially in federated healthcare environments where multiple hospitals, clinics, and systems exchange data.
But there was another challenge: scale. It wasn't just about a handful of resources. We had to handle more than 10,000 EpisodeOfCare records. Enhancing that many records required a reliable, scalable, and cost effective approach.
The solution came through batch processing, powered by Google Cloud Healthcare API, a Python-based enhancement engine, and serverless deployment on Cloud Run. The results were remarkable: thousands of resources enhanced in minutes, at low cost, with 100% success. Most importantly, the data became more useful for both people and systems.
1. Introduction: The Interoperability Challenge
In today's healthcare environment, data lives everywhere. Patients might receive care at multiple facilities across different regions, each with its own information system. These systems often don't agree on how to represent data.
FHIR was designed as a bridge, providing a standard way to share healthcare information. But standards leave room for interpretation, and sometimes that room creates gaps.
The EpisodeOfCare resource is a good example. It records the period during which a patient is under care, but the way it references patients and organizations often leaves out the details that make data useful in practice.
Here's what a typical EpisodeOfCare resource looked like before enhancement:
{
"patient": {
"reference": "Patient/f0c29c2a-1f20-4b9f-b49c-8d4ad487a6e8"
},
"managingOrganization": {
"reference": "Organization/100007732"
}
}
On the surface, it seems fine. But in practice:
- The patient's name is missing.
- Their identifier, such as a national ID (NIK), is missing.
- The organization's name is missing.
This makes queries harder. If you want to filter EpisodeOfCare resources by patient name, you can't do it directly. If you want to find all patients managed by a specific hospital, you have to look up organization codes separately. In federated systems, where data needs to be shared seamlessly across multiple institutions, this lack of clarity makes interoperability fragile.
The result: more work for healthcare staff, more room for errors, and less effective use of valuable data.
2. Our Approach: Adding the Missing Pieces
We set out to make EpisodeOfCare resources more useful, more searchable, and more interoperable.
The key was enhancing the references so that they carried not just codes, but context.
- Patient identifiers (NIKs): By embedding identifiers directly into EpisodeOfCare, we made it easy to query by ID and match patients across systems.
- Patient display names: Adding names meant healthcare workers could instantly see who the record referred to, and systems could query resources by name.
- Organization display names: Embedding the managing organization's actual name improved both usability and data federation across institutions.
Here's what the same resource looked like after enhancement:
{
"patient": {
"reference": "Patient/f0c29c2a-1f20-4b9f-b49c-8d4ad487a6e8",
"display": "Dr. YULIANI SUSANTI",
"identifier": {
"system": "https://fhir.kemkes.go.id/id/nik",
"value": "3271234567890123"
}
},
"managingOrganization": {
"reference": "Organization/100007732",
"display": "RSUD PURBALINGGA"
}
}
Now, queries become much simpler. Need to find all patients managed by RSUD PURBALINGGA? You can query directly on the display field. Need to check for duplicate NIKs? The identifier is already there.
By enriching references, we didn't just improve usability, we made the data easier to search, more consistent across systems, and more reliable in federated environments.
3. The Big Challenge: Scaling Up
Enhancing one EpisodeOfCare resource was easy. Enhancing over 10,000 resources was a serious technical challenge.
Processing each record individually would have been too slow and too fragile. We risked hitting API rate limits, overloading memory, and wasting time. In a federated environment, where performance and reliability are critical, this was unacceptable.
The solution was batch processing. Instead of treating each record as a separate job, we processed them in groups. This allowed us to control throughput, recover gracefully from errors, and optimize performance.
With smart pagination and configurable parameters, the system could handle datasets of any size. Whether it was 1,000 records or 10,000, the engine processed them efficiently.
In practice, this meant:
- Thousands of resources processed in under half an hour.
- Hundreds of API calls per minute without hitting limits.
- Full runs costing less than a dollar, even at large scale.
The leap from hundreds to tens of thousands of records proved that the system wasn't just functional; it was scalable.
4. Inside the Engine
At the heart of the system was a Python-based enhancement engine. Its job was to fetch EpisodeOfCare resources, enrich their references, and save them back in enhanced form.
The logic for enhancing patients, for example, looked like this:
def enhance_patient_reference(self, patient_ref, patient_resource):
"""Add NIK identifier and display name to patient reference"""
enhanced_ref = patient_ref.copy()
nik = self.extract_nik_from_patient(patient_resource)
if nik:
enhanced_ref['identifier'] = nik
display_name = self.extract_patient_display_name(patient_resource)
if display_name:
enhanced_ref['display'] = display_name
return enhanced_ref
This small piece of code hides a lot of sophistication. It knows how to handle multiple NIK formats, build names from different components, and gracefully skip enhancements if data is missing.
But beyond the logic, what mattered most was resilience. Logs tracked every step. Failed calls retried automatically. Errors didn't crash the process. They were logged, and the batch continued. This was essential for handling more than 10,000 records without losing progress.
And of course, everything was designed with security and compliance in mind. Data was encrypted in transit and at rest, authentication was handled securely, and every enhancement left an audit trail.
5. Deployment in the Real World
We chose Google Cloud Run to deploy the service. This gave us a serverless platform that scaled automatically and required almost no infrastructure management.
Each region had its own deployment, with its own configuration. For example, Purbalingga and Lombok Barat each had dedicated endpoints, tuned for their workloads.
We added features that made operations smooth:
- Health-check endpoints to confirm the system was running.
- Monitoring dashboards to track progress.
- Dry-run mode to test enhancements safely.
- Automated deployment scripts for fast updates.
The result was a production-ready system that didn't just work in theory, but in the complex, messy reality of healthcare IT.
6. The Results
The numbers tell a powerful story:
- Over 10,000 EpisodeOfCare resources enhanced
- 100% success rate
- Zero data loss
- 293 API calls per minute sustained
But behind the numbers were the real wins:
- Doctors could query patients by name or ID without extra clicks.
- Administrators no longer had to translate organization codes manually.
- Federated systems could exchange EpisodeOfCare data more reliably, because references carried meaningful context.
Healthcare workers reported that tasks which once took minutes now took seconds. And across organizations, interoperability became less of a headache.
7. Looking Ahead
As we reflect on the project, one theme stands out above all others: the importance of the federated healthcare ecosystem.
Healthcare is rarely contained within a single system. Patients move between clinics, hospitals, insurance providers, and government programs. Each of these organizations may run its own IT infrastructure, but the real challenge, and the real opportunity, comes when they need to share data with one another.
This is where enhanced EpisodeOfCare resources make a difference. By embedding identifiers, display names, and organization names directly into the references, we remove friction. Instead of systems struggling to reconcile codes or run complicated joins, they can exchange data that already carries meaningful context.
In a federated setup, this means:
- Queries become easier across institutions, because identifiers and names are consistent and visible.
- Data exchange becomes more reliable, because the meaning of each reference is clearer.
- Patient journeys can be tracked more smoothly, even when care happens across multiple organizations.
The future we see isn't about adding more technology for its own sake. It's about making the data we already have work better in a federated world, where collaboration between systems is the norm, not the exception.
8. Conclusion: Data That Works Better
At the start, our challenge was simple: EpisodeOfCare resources weren't very helpful to humans. They carried references, but not enough detail.
By enhancing those references, we solved three problems at once: we made queries easier, improved day-to-day usability, and strengthened interoperability across federated systems.
Scaling to more than 10,000 records proved that the solution wasn't just a prototype it was production-ready. And deploying it on the cloud made it secure, cost-efficient, and easy to operate.
In the end, the lesson is clear: good healthcare data is about more than accuracy. It's about accessibility, usability, and interoperability. When data works better, healthcare works better.
This is one step toward a future where healthcare systems truly work together, seamlessly and intelligently. And if there's one takeaway from our journey, it's that improving interoperability doesn't always require massive overhauls. sometimes, it just takes the right enhancements, applied at the right scale.
Top comments (0)