ARTICLE AD BOX
I am working on integrating PhilHealth (Philippine Health Insurance Corporation) into an existing hospital management system built with ASP.NET Core (.NET), Entity Framework Core, and SQL Server.
At this stage:
We do not yet have access to official PhilHealth APIs, WSDLs, or sandbox endpoints
We do not have finalized XML schemas
Management still expects us to begin architectural and design work based on publicly available PhilHealth guidelines (CF1, CF2, eligibility, and claims workflow)
What I’m unsure about
Recommended overall architecture when official SOAP APIs are not yet available
How to properly split responsibilities between:
Domain services vs repositories
XML builders/serializers vs business logic
How to design the system so it can later support:
SOAP endpoints
Mutual TLS / certificate-based authentication
Separate test and production environments
Real-world handling of:
Eligibility → claim submission → claim status lifecycle
Retry, resubmission, and reconciliation strategies
Audit and compliance logging
Common mistakes to avoid when starting a PhilHealth (or similar government insurance) integration early
What I am not asking for
PhilHealth credentials
Proprietary WSDLs or internal documentation
Complete working implementations
What I am looking for
High-level architecture guidance
Design patterns suitable for SOAP/XML healthcare integrations
Lessons learned from similar government insurance systems
Advice on future-proofing the design before official onboarding
Any guidance from developers who have worked on PhilHealth, government insurance integrations, or similar SOAP/XML healthcare systems would be greatly appreciated.
