CarePoint
CarePoint is a comprehensive pharmacy and clinical management solution developed by Citrusbug, centralizing inventory, patient prescriptions, dispensing workflows, and compliance reporting for multi-location healthcare operations.
Radiologists and imaging teams work with incomplete infrastructure every day: PACS silos that don't talk to the EHR, AI models without a regulatory pathway, and DICOM pipelines built for on-prem that are now holding back cloud adoption. We build diagnostic imaging systems on DICOM 2024, HL7 FHIR R4B, and cloud-native PACS architecture so your clinical team gets the system that matches how imaging actually works today.
Request a Consultation
Trusted by industry leaders
Most diagnostic imaging failures are not caused by bad hardware. They are caused by a software layer that was assembled over time: a PACS from one vendor, a DICOM viewer from another, an AI module that outputs results in a proprietary format the EHR cannot read, and a cloud migration that stalled because nobody documented the DIMSE-to-DICOMweb transition correctly.
The consequence is not just slow image retrieval. It is radiologists spending 15-20 minutes per study on system friction, AI findings that live in a silo nobody checks, and a compliance posture that cannot answer basic audit questions about who accessed what image and when. The organizations that fix this do not patch the existing stack. They build a system with a defined architecture from day one.
Workflows that fragment imaging across three or more systems show measurably higher report turnaround time than unified platforms, with the gap widening at higher study volumes. PACS migrations to cloud-native DICOMweb architecture are the primary driver of that consolidation, and the teams that get there faster are the ones that started with a proper technical specification.
Tell us your current PACS setup and imaging volumes. We will scope a build plan within a week.
Start the Architecture ConversationBuilt on Azure Health Data Services DICOM service or AWS HealthImaging, using STOW-RS for ingest and WADO-RS for retrieval. Studies are indexed via FHIR ImagingStudy resource for EHR-linked access without DIMSE dependency.
PyTorch/MONAI-based inference pipelines for segmentation, anomaly detection, and structured finding generation. AI results are stored as DICOM 2024 AI Results objects, keeping findings within the imaging workflow rather than in a separate database.
Native integration with Sectra, Intelerad, and Ambra Health via DICOMweb and HL7 messaging. For organizations migrating to a VNA, the system is architected to support simultaneous DIMSE and DICOMweb operation during transition.
SMART on FHIR integration with Epic Hyperdrive, Cerner, and Oracle Health. Modality worklist management via DICOM MWL. FHIR R4B ImagingStudy and DiagnosticReport resources feed ordering and results workflows bidirectionally.
Automated report generation using RadLex-coded findings and LOINC observation codes. Templates configurable by modality and subspecialty. Reports surface in the EHR as FHIR DiagnosticReport resources rather than unstructured PDFs.
Role-based access control aligned with HIPAA minimum-necessary requirements. Full DICOM audit trail via ATNA (Audit Trail and Node Authentication) profile. Audit logs are tamper-evident and accessible for HIPAA breach response within the 72-hour ONC notification window.
We review your PACS infrastructure, modality types, study volume, and EHR contracts. Output is a documented architecture specification covering DICOM pipeline design, FHIR resource mapping, AI inference placement, and compliance scope.
We define the FDA pathway (510(k) or PCCP), applicable IEC 62304 software safety class, and required ISO 13485 artifacts including a SOUP audit of the intended stack. Doing this before development starts costs far less than retrofitting it afterward.
Ingestion and retrieval are built on DICOMweb-native services (STOW-RS/WADO-RS). For hybrid environments with legacy modalities, a gateway normalizes DIMSE and DICOMweb into a unified FHIR ImagingStudy index. Healthcare API integration is resolved at the architecture layer.
AI models are containerized as inference services, separate from the DICOM viewer. The FDA's 2025 PCCP guidance allows adaptive AI components to update post-clearance without a new 510(k) but only when the change control plan was part of the original filing. We build for that from the start.
SMART on FHIR authorization is configured for the target EHR. Orders pull from the RIS via modality worklist; results write back as FHIR DiagnosticReport and ImagingStudy resources. Report templates use RadLex and LOINC codes so findings feed downstream clinical decision support systems without re-entry.
Covers functional testing, peak-load performance, security penetration testing, and DICOM conformance statement generation per IEC 62304. The AI post-market monitoring plan, drift thresholds and retraining triggers, is defined here, not after go-live.
Operational Excellence
Tech Expertise
Consistent Commitment
Based on 43 Reviews
CT, MRI, PET-CT, digital X-ray, mammography, ultrasound, and whole slide imaging scanners. Modality worklist ensures orders are pulled before acquisition rather than manually entered at the scanner. DICOM transfer syntax normalization handles multi-vendor environments.
DICOMweb WADO-RS and STOW-RS for cloud-native systems. Legacy DIMSE (C-FIND, C-MOVE) for existing PACS during migration periods. Vendor-neutral archive routing rules ensure the right study lands in the right destination based on modality type, site, and patient demographics.
Epic Hyperdrive, Cerner Millennium, and Oracle Health via SMART on FHIR. HL7 v2 ADT and ORM messages for legacy integration points. FHIR ImagingStudy and DiagnosticReport resource creation on study completion.
Bidirectional HL7 ORM/ORU messaging for order management. Worklist population from RIS to modality. Results routing from PACS to RIS for billing and scheduling workflows.
Inference services are deployed as containerized APIs that receive DICOM instances and return structured findings in DICOM SR (Structured Report) or FHIR Observation format. AI results are kept within the DICOM workflow, not in a separate proprietary database.
The architecture of a compliant diagnostic imaging system is defined by the standards layer it runs on, not by the list of features.
Scoped engagements range from $35,000 to $70,000 for a core DICOM pipeline with PACS and EHR integration. Full SaMD development with IEC 62304 documentation and FDA PCCP preparation typically runs $100,000 to $200,000+, depending on AI scope and modality coverage.
| Modality | DICOM Transfer Syntax | AI Layer | Structured Reporting | EHR Result Feed |
|---|---|---|---|---|
|
CT (Computed Tomography) |
Yes (JPEG 2000, JPEG-LS) |
Segmentation, nodule detection |
RadLex + LOINC coded |
FHIR DiagnosticReport |
|
MRI (Magnetic Resonance) |
Yes (Implicit/Explicit VR) |
Brain lesion, cardiac chamber analysis |
RadLex + LOINC coded |
FHIR DiagnosticReport |
|
Digital X-Ray |
Yes (JPEG Lossless) |
Fracture detection, chest triage |
RadLex + LOINC coded |
FHIR DiagnosticReport |
|
Ultrasound |
Yes (JPEG Baseline) |
Measurement automation |
Structured (limited) |
FHIR DiagnosticReport |
|
PET-CT |
Yes (JPEG 2000) |
Lesion SUV quantification |
RadLex + LOINC coded |
FHIR DiagnosticReport |
|
Whole Slide Imaging (Pathology) |
Native DICOM (2024) |
Tissue segmentation, cell counting |
Structured pathology report |
FHIR DiagnosticReport |
Most teams building AI into a diagnostic imaging system understand that FDA clearance is required for software that meets the SaMD definition. Fewer understand what changed in 2025.
The FDA’s Predetermined Change Control Plan guidance allows AI imaging components to be updated within predefined performance thresholds after initial clearance, without filing a new 510(k). The condition: the change control plan must have been submitted as part of the original application. Teams that did not build for this at the architecture stage are locked into static models. Every performance improvement requires a new submission, at an average of 142 days per cycle.
The practical implication is that the architecture decision made during initial build determines how fast the AI layer can improve after go-live. Citrusbug designs AI inference components with the PCCP framework in mind from day one. The model training pipeline, performance thresholds, and drift detection mechanisms are defined before submission, not after the clinical team asks why detection accuracy dropped six months in.
This is what organizations working on medical image analysis software often miss when evaluating vendors: the question is not just “can you build it?” The question is “how do you build it so the AI layer can actually evolve after clearance?”
We will map your current architecture, define the compliance scope, and give you a realistic build estimate before the engagement starts.
We do not treat DICOM as a checkbox. DICOMweb, WADO-RS, STOW-RS, modality worklist, DICOM SR, and AI Results object support are all built to the 2024 standard, not the 2013 baseline most vendors reference.
Our Secure ADLC delivery methodology produces IEC 62304-aligned documentation as part of the standard build process. For SaMD-scope systems, SOUP assessment and DHF artifacts are not added at the end. They are produced during development.
AI inference is deployed as an architecture layer your team controls, not a third-party API you depend on. Model retraining pipelines, post-market monitoring, and FDA PCCP change control plans are handed over as deliverables, not retained by us.
Every integration (PACS, EHR, RIS, modality) is documented as a formal interface specification before development begins. This eliminates the go-live failures that come from assuming HL7 or FHIR behavior without testing against actual system endpoints.
Requirements, architecture documentation, user stories, and interface specifications are completed before development starts. This process is what separates systems that validate cleanly from those that consume 40% of the budget in rework.
You receive complete source code, documentation, and build artifacts at delivery. There is no Citrusbug-specific dependency that creates vendor lock-in after the engagement ends. Your team or any future vendor can maintain, extend, or re-platform the system.
CarePoint is a comprehensive pharmacy and clinical management solution developed by Citrusbug, centralizing inventory, patient prescriptions, dispensing workflows, and compliance reporting for multi-location healthcare operations.
A state-of-the-art wellness and patient engagement platform built for Mediyoga, integrating guided care programs, health tracking, and provider-patient communication into a unified digital experience.
Designed for healthcare providers and researchers, the platform enhances early detection of neurological conditions
PACS stores and retrieves images for a department or facility. A VNA is vendor-neutral and spans multiple PACS. A diagnostic imaging system is the complete software layer: acquisition, storage, AI analysis, structured reporting, and EHR integration, built as a unified architecture.
FDA clearance depends on whether the software qualifies as Software as a Medical Device (SaMD) and its intended clinical use. Systems that perform analysis or influence diagnostic decisions, such as AI-based anomaly detection, typically require clearance. Pure viewing or storage solutions may not, but this depends on functionality and claims. We assess this during discovery before development begins.
A core DICOM pipeline with EHR integration typically takes 4 to 6 months. Adding an AI inference layer and structured reporting adds 6 to 10 weeks. SaMD documentation and regulatory prep adds 8 to 14 weeks on top of development, depending on software class.
Yes. Integration uses SMART on FHIR authorization and FHIR R4B ImagingStudy and DiagnosticReport resources. We do not require replacing the EHR. We connect to what is already deployed.
We define the post-market monitoring plan during development. This includes performance thresholds, drift detection triggers, and the retraining pipeline. For FDA-cleared AI components, the PCCP framework allows updates within the defined bounds without a new 510(k).
Multi-vendor modality environments are normal. We implement DICOM transfer syntax normalization and a gateway layer, where needed, to ensure a 1990s-era DICOM 3.0 scanner and a current-generation CT produce studies that the system can consistently process and store.
We support embedded engagement where Citrusbug architects and senior engineers work directly within your sprint cycles. Source code, documentation, and architecture decisions belong to your team throughout. This avoids the knowledge transfer bottleneck that happens when the vendor hands over a finished system at the end.