Developer journeys
Build vs Integrate vs Modernize
Choose the right Mediloop adoption path for a greenfield product, an existing healthcare system or a legacy modernization programme.
Three adoption paths
Build
Use Mediloop APIs as healthcare building blocks for a new application or a new product module.
Integrate
Keep an existing system and connect it to selected Mediloop services and standards.
Modernize
Replace legacy capabilities progressively while the original application continues to operate.
Build with Mediloop
1
Your product experience
Web, mobile, desktop or partner application
2
Mediloop APIs & SDKs
Stable contracts and developer tooling
3
Healthcare capabilities
Identity, FHIR, workflows, devices and more
4
Production
Onboard, monitor and operate
Best when you control the new application architecture.
Choose only the APIs required by your product.
Keep your frontend framework independent from healthcare service contracts.
Use SDKs for developer productivity, not as a mandatory coupling to Mediloop internals.
Integrate Mediloop
1
Existing system
System remains in place
2
Integration surface
REST, FHIR, HL7, DICOMweb, webhooks or connectors
3
Governance
Identity, tenant context, scopes and audit
4
Selected Mediloop services
Add capabilities without full replacement
Best when the existing system remains the operational or clinical system of record.
Define data ownership and reconciliation before connecting bidirectional flows.
Use protocol-native integration where that is the safest and most interoperable path.
Prefer standards-based exchange over creating new proprietary interfaces.
Modernize with Mediloop
1
Assess legacy domains
Find expensive, risky or obsolete components
2
Choose boundaries
Identity, scheduling, FHIR, imaging, devices, etc.
3
Run side by side
Route selected traffic to Mediloop while legacy continues
4
Migrate progressively
Cut over one validated capability at a time
5
Retire legacy modules
Decommission only after stable production operation
Decision matrix
| Question | Build | Integrate | Modernize |
|---|---|---|---|
| Is this a greenfield product? | Strong fit | Possible | Usually no |
| Must the existing system remain in service? | Not required | Yes | Yes, during migration |
| Do you want to replace old modules? | Optional | Usually no | Primary goal |
| Can migration happen progressively? | N/A | Yes | Yes — recommended |
| Primary interfaces | REST/FHIR/SDK | APIs + connectors + standards | APIs/SDKs + adapters + dual-run |
| Typical risk profile | New-product delivery | Integration/change management | Migration and cutover management |
Combine the paths
Real programmes often use all three paths
A hospital vendor may build a new React interface, integrate its existing LIS and PACS, and modernize authentication and scheduling progressively. The paths are architectural strategies, not mutually exclusive product tiers.