Carta Healthcare

Lighthouse depends on learned models to interpret clinical records and suggest answers to registry questions. Its AI work includes reading narrative documentation, finding supporting passages, and connecting an answer to its clinical context. Voyager supplies the underlying ingestion and model orchestration, while experienced abstractors retain the final decision. Carta also sells abstraction personnel, Atlas workflow and submission functions, and Navigator analytics.

Those services give the wider business value beyond the model itself. A hospital can purchase technology for an existing abstraction team or combine it with Carta personnel, making the AI central to the software module without making every part of the offering an autonomous AI service.

An abstractor reviews each proposed registry answer with its justification, supporting chart excerpts, links to the full source documents, and the sponsor's coding instructions. The person confirms the answer and resolves ambiguous clinical documentation. Voyager uses read only EHR access and does not write changes into the patient record, which limits the actions the model can take in that system. This is a concrete review workflow with an identifiable decision maker.

Confidence thresholds that suppress a suggestion, mandatory escalation criteria, and a recovery procedure for an incorrect or omitted answer remain unspecified. Human review is established, while the rules governing uncertain cases are less clear.

Anthropic Claude supplies the language model through AWS Bedrock. Voyager adds Carta technology for temporal reasoning, reducing unsupported answers, and linking suggestions to chart evidence. It ingests structured FHIR resources and unstructured clinical documents before producing answers for registry workflows. That identifies both a foundation model supplier and the clinical tasks around it.

The production Claude version, training or adaptation data used for Carta components, evaluation criteria for replacements, and update schedule remain unspecified. Weekly registry definition updates change the instructions used in abstraction, but do not establish when the underlying model changes or how a replacement is approved.

Claude is supplied by Anthropic through AWS Bedrock rather than by a separately identified Carta foundation model. Carta adds proprietary clinical processing, and the hosted environment also uses AWS infrastructure for storage and operation. Customer data is barred from external model training and is technically separated from model vendors. This identifies the main model supplier and an important processing route.

A complete product subprocessor register, the precise information each party can access, and provider specific retention terms remain unavailable. The website privacy notice's examples of marketing and CRM providers do not establish the processor chain for hospital records.

UNC Health provides a Lighthouse user account, and a January 2026 case describes an experienced abstractor finding supporting information faster. Its example of 20 minutes saved concerns a hypothetical comparison with earlier work, rather than a measured current evaluation. Northern Arizona Healthcare's separate case follows a combined abstraction partnership from the third quarter of 2023 to the second quarter of 2024.

That project sampled at least 5% of monthly cases for inter-rater checks and improved a CathPCI documentation benchmark. It establishes experience with the service and process changes, but does not isolate the current Lighthouse model. A dated, reproducible evaluation of today's software alone remains unavailable.

Hospital information is separated by customer, and Carta commits that it is not used to train external models. Voyager processes records through AWS Bedrock, with technical separation from model vendors and a dedicated customer environment. The workflow returns evidence to an abstractor for validation, rather than automatically changing the EHR.

These commitments address external training and some exposure risks, but the PHI retention period, deletion behavior, and deidentification rules remain unspecified. Claims about reducing hallucinations do not explain detection thresholds or testing. A defined response to an AI safety event, including investigation and correction of affected abstractions, is also unclear.

Carta states that client PHI is governed by HIPAA and customer business associate agreements, and Voyager carries a commitment to BAAs with customers and vendors. The December 2025 privacy notice explicitly excludes the patient information handled through Atlas, Voyager, and Lighthouse. Its visitor rights, marketing data practices, and website service provider provisions therefore do not establish the terms for hospital records.

Dedicated customer environments and encryption address technical handling, but do not replace the agreement's legal scope. A readable customer BAA, its detailed subcontractor obligations, and substantive service privacy terms remain unavailable before contracting.

Voyager carries an annual independent SOC 2 audit claim alongside encryption and separation of customer data. Technical controls include AES-256 encryption at rest, TLS 1.2 or later in transit, dedicated AWS customer accounts, and monitored workloads. Those details describe protection of the hosted abstraction environment, while HIPAA BAAs address a separate set of customer and vendor responsibilities.

The SOC reporting type, current reporting period, auditor, full system scope, and route to obtain the report remain unspecified. Without the actual attestation, the audit claim cannot establish which components or model processing services are covered by the current examination.

Lighthouse supports retrospective clinical registry abstraction by organizing existing documentation for a trained abstractor. Voyager reads records, and Atlas supports abstraction workflow and registry submission. Navigator uses the resulting data for quality improvement and research analytics. These functions are positioned as clinical data management, with human confirmation of registry answers, rather than an independent diagnostic or treatment decision system.

No medical device clearance is claimed for the current offering. Its HIPAA, security audit, and registry relationships address different responsibilities and do not establish FDA authorization for a future clinical use outside that stated scope.

Clinical experts validate suggested answers and resolve ambiguity, while registry definitions reach Lighthouse through weekly updates informed by relationships with registry sponsors. The abstraction service also uses quality assurance processes; Northern Arizona Healthcare's earlier engagement included regular inter-rater checks, daily tracking, and weekly review of missing fields. Those practices govern registry work and documentation quality.

They do not establish the current model's performance across hospitals, demographic groups, specialties, or difficult record types. A defined model change approval process, comparative fairness evaluation, and release acceptance criteria remain unspecified. Earlier service quality results cannot establish governance of a newer model release.

An abstractor can inspect the passages behind a suggested answer and open the original document before confirming a registry field. Registry coding instructions provide another reference for challenging the output, and the combined service adds clinical personnel and quality review. These mechanisms make an individual abstraction reviewable.

They do not establish an output accuracy warranty, compensation for an incorrect submission, or a contractual obligation to correct all affected records after a model error. Website privacy rights apply to visitor information and expressly exclude client PHI, so those rights are not a patient chart correction route through Carta's abstraction service.

Voyager connects through FHIR APIs using read only access. Supported resource types include Patient, Encounter, Observation, DocumentReference, Medication, Procedure, and Condition, giving the abstraction workflow both clinical data and document references. Prebuilt integration apps are offered, with a one day implementation claim that depends on hospital readiness.

The system does not modify or write information back to the EHR, and Lighthouse remains alongside existing registry submission tools. A named EHR tied to a current production Voyager connection is still unspecified. Fivos' separate Epic and Oracle Cerner integration examples establish that partner's capabilities, but do not by themselves prove a Carta deployment on those systems.

Each hospital receives a dedicated AWS account, and the service uses a single tenant environment with encrypted storage and monitored workloads. Model processing runs through AWS Bedrock, while AWS EKS supports horizontal scaling. Disaster recovery can span regions, and managed service support operates under defined service levels. These details establish meaningful customer separation and infrastructure choices.

They do not identify the storage country, permitted inference regions, or the locations used for regional recovery. An on premises option and the complete cross border processing boundary remain unspecified, so customer isolation does not establish a commitment to a particular national residency.

Hospitals can license Lighthouse for their own abstractors or outsource part or all of abstraction to Carta personnel using the technology. In the Fivos distribution arrangement, charges scale with case volume and include implementation, training, maintenance, and support. That arrangement describes $0 upfront cost but does not give the per case amount.

A separate annual Fivos OpenPathways API subscription can also apply, so the technology and registry connection are distinct cost components. The purchasing structure is understandable before contact, while current volume bands, minimum commitments, and a complete price for a particular hospital remain unspecified. Savings percentages do not establish the subscription or service charge.

Hospital and health system registry teams are the principal users. The abstraction service covers more than 30 registries and combines clinical personnel with software for collecting and reviewing registry information. Northern Arizona Healthcare supplies a named cardiovascular example involving CathPCI fields, including pre-TIMI flow and post-stenosis documentation. UNC Health provides a current Lighthouse user account, supporting a hospital abstraction setting for that module.

Navigator extends the resulting information into quality improvement and research analytics. These examples establish parts of the intended coverage, while equivalent current software validation across all supported specialties, registry definitions, and source record types remains limited.