**About Vitestro**

Founded in 2017 in Utrecht, Vitestro is pioneering the future of blood collection with the**Aletta® Autonomous Robotic Phlebotomy Device™ (ARPD™)** . This groundbreaking medical device combines advanced multi-modal imaging (near-infrared, ultrasound, and Doppler ultrasound) with robotics and AI to perform the entire diagnostic blood draw procedure autonomously.

By addressing critical healthcare staffing shortages and improving patient experience, Vitestro is transforming one of the most common and essential medical procedures. With more than 90 team members and growing rapidly, we are scaling our impact. As we placed our first devices with customers, we are now expanding our team to ensure successful implementation and long-term reliability.

At Vitestro, we are committed to continuous innovation and improvement.

**The Assignment**

Vitestro is building the LIS (Laboratory Information System) integration gateway that connects hospital laboratory systems to our venipuncture device platform. We have selected **Apache Camel on Quarkus** as the target architecture: a stateless, container-per-hospital gateway that can run centrally in AWS or on-premise at a hospital, with hard OS-level data isolation between tenants and zero-code onboarding of new hospitals via configuration.

Our internal Platform \& Connectivity team does not have the capacity to deliver this build within our commercial timeline, so we are looking for an experienced freelancer/contractor (or small team) to build the initial gateway. A permanent Integration Engineer will take over operation, maintenance, and hospital-by-hospital rollout once the gateway is delivered --- so a clean, well-documented handover is a hard requirement of this assignment, not an afterthought.

**Key Deliverables**

* Design and build the universal, stateless Camel Quarkus gateway image: one codebase, hospital identity/config/transformations externalized and injected at container boot

* Implement the reliability properties required for clinical use: guaranteed delivery, idempotent consumption, redelivery and dead-letter handling, end-to-end traceability and replay, no silent data loss

* Implement the security and compliance baseline: hard container-level tenant isolation, mTLS with dynamic certificate retrieval from Secrets Manager, and the LogMasker component (PII/PPID/BSN masking before logs leave the container)

* Build the configuration-driven onboarding mechanism: hospital-specific JSON mapping tables and credentials streamed from S3/Secrets Manager at container startup, with zero code changes per hospital

* Deliver the gateway as a deployable OCI/Docker image, validated to run both centrally in AWS (ECS/Fargate) and --- as a target capability --- inside a hospital's own on-premise infrastructure

* Deliver a first working end-to-end connection to at least one GLIMS-based hospital as proof of the onboarding mechanism, to de-risk the "configuration, not code" claim before handover

* Set up CI/CD and infrastructure-as-code for the gateway, so environment and route configuration are version-controlled and reproducible

* Validate the published Quarkus native performance assumptions (boot time, idle memory footprint) against our actual route/component footprint, and flag any deviation from the architecture document's assumptions

**Handover Requirements (critical)**

* Full technical documentation of the gateway architecture, route structure, and configuration schema --- written so an integration engineer without prior Camel exposure can maintain and extend it

* A working example/template for onboarding a new hospital, documented step by step

* Runbook for common operational scenarios: certificate rotation, failed delivery/dead-letter recovery, adding a new LIS variant

* Structured knowledge-transfer sessions with the incoming Integration Engineer before contract end

* Codebase and infrastructure-as-code left in a state that a mid-level backend engineer can operate without ongoing dependency on the contractor

**Out of Scope**

* Ongoing hospital-by-hospital rollout after initial validation (owned by the incoming Integration Engineer)

* Device/IoT fleet management (provisioning, OTA updates, telemetry) - separate workstream

* Long-term maintenance and support beyond the agreed handover period

**This is a full-time engagement expected to run approximately three to six months, starting mid-September 2026. Technical delivery is targeted for end of 2026, followed by testing and stabilization through Q1 2027 to support go-live with our first Dutch GLIMS hospitals, with the engagement concluding around mid-March 2027. The project wraps up with a full handover of the integrations and runbooks to peers at Vitestro.**