Cloud-native application development for MedTech, including the operating capability the application will require from the day it goes live.
A device company that builds a cloud application has changed what kind of company it is. A manufactured product is verified, released and shipped, and the organization that built it moves on to the next version. A cloud service is never shipped. It runs continuously, it is changed weekly, it fails at inconvenient times, and somebody has to be awake for it. Most MedTech organizations are structured for the first of those and discover the second after launch, which is why so many cloud programmes succeed technically and then struggle operationally.
The technical reasons for moving to cloud-native are usually sound and rarely disputed. The existing infrastructure cannot scale to the customer volume the roadmap assumes. The hosting arrangement was sized for a different product. Deployment takes a weekend and a change window. Security expectations from hospital customers have moved faster than the infrastructure has. Performance degrades at the times of day clinicians actually work. All of that argues for cloud-native and all of it is true.
What the business case usually omits is that every one of those problems is solved by taking on an operating responsibility the organization did not previously have. Elastic scale means capacity is now a continuous decision rather than a procurement one. Managed services mean a supplier is inside your product. Weekly deployment means change control runs weekly. Observability means somebody reads it. Each of these is an improvement and each creates an ongoing obligation, and the gap between the engineering plan and the operating plan is where cloud programmes in this industry actually fail.
Infrastructure cannot support the roadmap
The product was architected for the customer base it had, and growth is now an engineering constraint rather than a sales one.
Performance problems appear at clinical peak
Which is the worst possible time and the hardest to reproduce in a test environment.
Hospital security review has become a sales gate
Customers now ask questions about architecture, tenancy and encryption that the current hosting cannot answer well.
Release requires a window and a weekend
So changes batch up, each release is larger and riskier, and the cadence gets worse over time.
Nobody owns the running service
Engineering built it, support answers tickets about it, and there is no on-call rota because the company has never needed one.
Every service is green and the product is failing
Infrastructure availability is not workflow availability, and the dashboards measure the first one.
Reliability has no agreed definition
There is no target, no measurement, and no shared understanding of what an outage means for a clinical user.
Write the operating plan before the architecture is final. Who is on call, what they are expected to do, how an incident is distinguished from a complaint, what the availability target is and where it came from, who approves a deployment on a Tuesday, and what happens when the cloud provider has an outage you cannot fix. These answers constrain the architecture considerably, and they are almost always produced afterwards, at which point the architecture has already assumed a kind of organization that does not exist yet.
We treat the operating model as a design input rather than a deployment activity. The sequence below establishes what the service has to guarantee and who will be responsible for it before the architecture is committed, because those two answers change the design more than any technology decision does.
Step 1
Establish what the application does for the patient and the clinician
Step 2
Agree the regulated boundary with your quality function
Step 3
Define the service levels that follow from clinical use
Step 4
Design the operating model
Step 5
Choose tenancy and isolation deliberately
Step 6
Architect for the failure modes you can name
Step 7
Build the delivery pipeline first
Step 8
Develop incrementally against a real environment
Step 9
Qualify the cloud provider as a supplier
Step 10
Operate, measure and hand over deliberately
The design question is not which cloud. It is what you promise and who keeps the promise. Provider selection consumes a disproportionate share of the early discussion and determines very little about the outcome. The decisions that matter are the availability commitment and where it came from, the tenancy model, the regulated boundary, and whether the organization will have an operations function on the day the first clinical customer depends on the service. All four are unglamorous, none of them is a technology choice, and each is harder to change after launch than the provider is.
Three groups, in the order they are needed. The third is the one most commonly scoped out of the first engagement and the one that determines whether the application survives its second year.
Build
Cloud-native application architecture, including service boundaries, tenancy model and the isolation the customer base will require
Application and API development in current backend and frontend stacks, built to be testable rather than to be fashionable
Containerization and orchestration, with the runtime chosen against the operating capability that will exist
Serverless components where the workload pattern justifies them and the cold-start behaviour is acceptable to the use case
Event-driven integration and messaging, including ordering and replay semantics for anything carrying clinical data
Data architecture, storage selection, migration and the retention obligations your counsel defines
Deliver
Delivery pipelines that produce verification evidence as a build output rather than as a pre-release documentation exercise
Infrastructure as code for every environment, with drift detection, because an undeclared environment change is an uncontrolled change
Automated testing across unit, integration, contract, performance and recovery, scaled to the risk the component carries
Security scanning, dependency and component inventory, and the software bill of materials where it applies
Progressive delivery, including canary and staged rollout, with rollback that has been exercised rather than documented
Environment parity sufficient that a performance problem can be reproduced somewhere other than production
Run
Observability across logs, metrics and traces, instrumented during development rather than added after the first outage
Service level objectives derived from clinical consequence, with alerting that fires on those rather than on infrastructure noise
On-call structure, escalation path, incident process and the boundary between an incident and a complaint
Runbooks maintained by the people who are woken up, and exercised rather than filed
Capacity and cost management as a continuous practice, since elastic infrastructure makes both a running decision
Disaster recovery and business continuity, tested at a frequency your quality function agrees to
The architecture differs less between these than the operating commitment does. The third column is what the service has to guarantee, which is the figure that should drive the design and the staffing.
| Application type | What it does | What the operation has to guarantee |
|---|---|---|
| Digital health platform | Patient-facing care, coaching or therapy delivery | Availability during the hours patients use it, and a defensible position on retention and consent |
| Connected device cloud | Services the deployed fleet depends on | Continuous availability, plus graceful behaviour when the whole fleet reconnects at once |
| Remote monitoring | Receiving and surfacing patient data between visits | Timeliness as well as uptime, because late data and no data are clinically similar |
| Clinical application | Used by clinicians during or around care delivery | Availability at clinical peak, and performance that holds during it |
| MedTech SaaS | Analytics, portals and administrative tooling for customers | Tenant isolation strong enough to survive hospital security review |
Platform selection is the most discussed decision and among the least consequential. These six are the ones that are expensive to revisit, and each should be made explicitly and recorded with its reasoning.
| Decision | The real question | What it costs to change later |
|---|---|---|
| Regulated boundary | Which components sit inside device scope | Very high. It determines lifetime verification overhead for everything inside it |
| Tenancy and isolation | What one customer can do to another | High. It is embedded in the data model and the deployment topology |
| Data residency and ownership | Where records live and who is authoritative | High, and it is usually discovered during an enterprise sales cycle |
| Identity and access model | How clinicians, patients, devices and partners authenticate | Moderate to high, and it reaches every integration you have |
| Runtime and orchestration | What the team can actually operate at two in the morning | Moderate. Painful but survivable, unlike the first three |
| Cloud provider | Which vendor, which managed services, which lock-in | Lower than the discussion it generates, if the boundaries are clean |
Infrastructure as code means the environment is part of the product. Once the environment is declared in code it becomes a configuration item like any other: versioned, reviewed, traceable and subject to change control. That is a considerable gain, because for most device companies the production environment was previously the one part of the system nobody could describe precisely and nobody had under formal control. It also has a consequence teams do not anticipate. Drift between the declared state and the running state is no longer an operational untidiness, it is an undocumented change to a controlled artifact, and detecting it has to be automatic rather than occasional.
Every major cloud provider publishes a shared responsibility model and most teams have read it. The part that is consistently underestimated is how much sits on your side of the line. The provider secures the physical estate, the hypervisor and the managed service itself. Identity, access, network configuration, encryption key handling, data classification, retention, logging, the application and every configuration decision are yours, and the overwhelming majority of healthcare cloud incidents originate in that upper half rather than in the provider.
A certification held by the provider is also not a certification held by you. A compliant platform can host a non-compliant application without difficulty, and the obligations that apply to your product follow from what the product does rather than from where it runs. Your quality, regulatory and legal functions determine what applies. We build and evidence the engineering controls that support those determinations.
Cloud security
- Identity and access as the primary control surface, with least privilege applied to services and to people
- Encryption in transit and at rest, with key management and rotation treated as an operational process rather than a setting
- Network segmentation and private connectivity, so the blast radius of a credential compromise is bounded
- Dependency and component inventory maintained continuously, since cloud-native applications carry a long supply chain
Patient data
- Data classified before it is stored, because retention and residency obligations follow from the classification
- Minimisation applied deliberately, since the cheapest data to protect is the data not collected
- Audit logging sufficient to reconstruct who accessed what, retained to the period your counsel defines
- HIPAA where applicable, with the business associate position and sub-processor chain documented rather than assumed
Regulated scope
- Engineering controls capable of supporting the frameworks that apply, which may include FDA regulation, IEC 62304, IEC 81001-5-1 and ISO 13485
- Configuration management covering infrastructure code and environment definitions alongside application source
- Verification evidence produced by the pipeline, versioned with the release it belongs to
- Applicability, classification and validation strategy determined by your quality and regulatory functions rather than by us
Supplier and continuity
- The cloud provider and each managed service qualified as a supplier under your existing process
- Deprecation and change notification tracked, since the provider will retire things on their schedule
- An articulated position on provider outage, including what degrades and what the clinical user is told
- Exit and portability understood well enough to answer the question a hospital procurement team will ask
Distributed systems fail partially, intermittently and in combinations nobody designed. The difference between organizations that handle this well and badly is not the quality of the architecture, it is whether the failure modes were exercised deliberately in advance or encountered for the first time in production with clinical users attached.
| Failure | What it looks like |
|---|---|
| A dependency is slow rather than down | Requests queue, thread pools exhaust, and the failure propagates to services that had no fault |
| A device reconnects after days offline | Delayed data arrives out of order and has to keep its original measurement time |
| The same measurement arrives twice | A retry after a lost response creates a duplicate a clinician may read as a second reading |
| A service fails mid-transaction | Recovery has to establish whether the operation completed before deciding to repeat it |
| A deployment changes API behaviour | Older devices and clients that cannot be updated stop working correctly |
| Infrastructure recovers and processing does not | Services are healthy, the queue is still backed up, and nothing reports it |
| The fleet reconnects simultaneously | Recovery load far exceeds peak, extending a brief outage into a long one |
| A managed service is degraded regionally | Your application is healthy and unusable, and the provider status page is behind events |
| A deployment is bad and rollback is not clean | A schema or contract change made the reverse path harder than the plan assumed |
| Performance collapses at clinical peak | The system is fine at test load and constrained at the hour that matters most |
| Credentials or keys expire unattended | A certificate nobody owned lapses and takes down an integration at the weekend |
| Observability fails with the service | The telemetry pipeline shares the dependency that failed, so the incident is invisible |
| Cost scales with the incident | Autoscaling responds to a failure loop and the spend becomes its own emergency |
Cloud programmes are reported as services deployed, migrations completed and platforms adopted. The outcomes that survive scrutiny are about whether the thing can be operated: whether it holds up at clinical peak, whether somebody is responsible for it, whether it can be changed on a Tuesday, and whether it recovers when the provider has a bad day.
| Category | What we measure | Why it matters |
|---|---|---|
| Availability against clinical need | Measured from the user, against a target derived from consequence | The only availability figure that means anything to a clinician |
| Performance at clinical peak | Response time during the busiest clinical hour, not the daily average | Averages conceal exactly the period the product is judged on |
| Deployment frequency and lead time | How often change ships and how long it takes to get there | The measure of whether the pipeline and change control actually work together |
| Change failure rate and recovery time | Proportion of deployments causing degradation, and time to restore | Deployment frequency without this pair is a risk metric, not an achievement |
| Recovery demonstrated | Last date a full restore was performed end to end, and how long it took | Distinguishes a recovery capability from a backup policy |
| Operating readiness | On-call coverage, runbook currency, alert precision and open incident actions | The capability gap that decides whether year two is sustainable |
We will establish what the service has to guarantee and why, design the operating model alongside the architecture, agree the regulated boundary with your quality function, build the application and the pipeline that evidences it, and hand over a service your team can actually run.
CaliberFocus is a MedTech engineering partner delivering cloud-native application development together with the operating capability to run it as a clinical service. From service levels derived from clinical consequence and deliberate tenancy decisions to delivery pipelines that produce verification evidence, observability and tested recovery, we build applications your team can operate, change and trust from the day the first clinical customer depends on them.
- Operating model designed alongside the architecture
- Availability targets derived from clinical consequence
- Pipelines that generate verification evidence as a build output
- Recovery, rollback and failure modes exercised before go-live
Security & Compliance
