Current public integration boundary
- No named connector claimCompatibility with Oracle Health, Epic, TrakCare, or another HIS must be validated with the hospital and vendor.
- No patient-data requirementThe core pilot should use the minimum operational fields needed for dispatch and communication.
- No public API credentials or routesTechnical endpoints, schemas, keys, and test procedures are shared only through the protected client process.
- No production promise from a mock-upDiagrams and sample payloads are design material until an implemented connector is tested and approved.
What the assessment covers
- Systems and ownershipSource system, data owner, support owner, vendor dependencies, and environments.
- Data and privacyField-level inventory, purpose, lawful basis, residency, retention, deletion, and transfer paths.
- SecurityAuthentication, least privilege, secrets, network controls, logging, rate limits, failure handling, and incident response.
- ReliabilityTimeouts, retries, idempotency, monitoring, reconciliation, rollback, and business-continuity fallback.
- AcceptanceSandbox evidence, hospital sign-off, runbook, support contacts, and production release criteria.
Important: A hospital integration is not production-ready merely because the source system supports REST, FHIR, HL7, webhooks, or CSV. The specific deployment must be implemented and tested.
Start with a controlled pilot
The recommended first step is a 30-day standalone pilot of the selected module. Integration work begins only when it has a named owner, approved data flow, signed scope, non-production test environment, and measurable acceptance criteria.