Working With SATUSEHAT
Lately I've been spending a lot of time exploring SATUSEHAT integration flows — reading implementation guides, testing endpoints, mapping healthcare data, and trying to understand how interoperability is being implemented in practice.
The technical challenge itself isn't surprising.
Healthcare systems are naturally complex.
Once you start dealing with:
- FHIR resources,
- terminology standards,
- patient workflows,
- interoperability requirements,
- and regulatory compliance,
complexity becomes unavoidable.
I don't think anyone seriously working in healthcare technology expects things to be simple.
But after spending more time with these integrations, I kept thinking about one specific question:
Where does all of this complexity actually end up?
And I think that's where the real issue begins.
Complexity Is Inevitable
Interoperability at national scale is difficult.
There are legitimate reasons why healthcare systems become complicated:
- healthcare data is sensitive
- clinical workflows vary between institutions
- terminology needs standardization
- systems need long-term compatibility
- regulations continuously evolve
None of these are trivial problems.
In many ways, complexity is the price of building healthcare systems that are interoperable, auditable, and nationally connected.
The problem is not that SATUSEHAT is complex.
The problem is how much of that complexity gets pushed downstream.
The Burden Falls on Hospital IT Teams
A national platform has significant advantages:
- larger engineering capacity
- institutional authority
- centralized standards
- financial resources
- long-term policy support
In theory, that position should help reduce implementation burden for hospitals.
But in practice, much of the operational complexity still lands directly on hospital IT teams.
And many hospitals are not operating with massive engineering departments.
Some teams are already responsible for:
- SIMRS maintenance
- infrastructure and networking
- BPJS integrations
- internal support requests
- reporting systems
- PACS and RIS deployments
- regulatory compliance
Then interoperability implementation gets added on top of all of that.
Not as a small feature.
But as an entirely new ecosystem of standards, workflows, and integration requirements.
The Gap Between Policy and Operational Reality
From a policy perspective, interoperability sounds straightforward:
- standardize data,
- connect systems,
- improve healthcare coordination.
And conceptually, that direction makes sense.
But implementation reality is much messier.
Hospital IT teams are expected to absorb:
- technical complexity,
- operational pressure,
- evolving requirements,
- and compliance responsibility,
often with limited time and limited engineering resources.
The result is that interoperability stops feeling like a collaborative ecosystem improvement initiative.
Instead, it can start feeling like an additional operational burden that hospitals are forced to absorb.
Complexity Distribution Matters
The more I work in healthcare technology, the more I realize something important:
Complexity itself is not the enemy.
The real question is:
Who is expected to handle that complexity?
Because every layer of friction pushed downstream creates additional pressure for the institutions implementing it.
And in healthcare, those institutions are often already operating under significant operational constraints.
That's why implementation design matters.
Not just standards.
Not just compliance.
But the actual day-to-day experience of the engineers and IT teams expected to make these systems work.
Closing Thoughts
I still believe interoperability is necessary.
National healthcare ecosystems require standardization, and building systems at this scale is never easy.
But successful interoperability is not only about designing standards.
It's also about understanding the operational realities of the people expected to implement them.
Because when implementation burden grows faster than institutional capacity, complexity doesn't disappear.
It simply gets pushed downstream.