What do you use CAIRE Connect for?
CAIRE Connect connects CAIRE with a customer’s other systems. It shares permitted planning input, reads published plans and analysis, and receives requests for a planner to decide. Access is controlled by organisation, connection, client and unit.
For example, import visit data from an operational system, review it in CAIRE, create a plan and let the other system follow its status. Another use is opening a read view of analysis or a plan from a partner solution. The scope depends on the version and features enabled for the customer.
Examples from a normal working week
- Planner: import a period from Carefox, review clients, visits and staff, and accept the input before creating a schedule. Use the customer’s existing source data for planning in CAIRE.
- Operations manager: use available analysis to follow continuity and time allocation. A connected system can read results made available within its granted access.
- Partner developer: read published plans and visits for permitted units, follow request status and receive permitted webhook events. The client provides a bounded integration with the customer’s CAIRE organisation.
- AI tool user: connect through MCP and ask about a unit’s planning, continuity or unassigned visits where the corresponding tools exist. Review proposals and make decisions in CAIRE.
What goes in, what comes out and who decides?
- Into CAIRE through Carefox: the selected import flow’s people, care and visit input for a chosen unit and period. The planner reviews scope and warnings before Accept.
- Inside CAIRE: accepted standing data, a dated schedule and a solved planning result are separate steps. Import does not automatically start optimisation or publication.
- Out of CAIRE through Partner API: published planning fields, available analysis and receipts admitted by the client’s scopes, data classes and unit list. The Carefox connection is one-way: CAIRE reads from Carefox and changes nothing there.
- Requests into CAIRE: the partner submits a supported request and follows its status. The planner decides through the workflow; a technical acknowledgement is not an operational decision.
- To an AI tool through MCP: the data returned by the invoked tools within the user’s permissions. Use an AI tool approved by the organisation for the task and data involved.
A concrete workflow: from source data to a published plan
- 1. Choose the source and scope: the administrator connects the system and limits access to the appropriate organisation, units and data.
- 2. Import and review: the planner selects a period and checks people, visits, shifts and warnings in the available import workflow.
- 3. Accept the input: the planner approves the data to use in CAIRE. Import is a separate step with a traceable result.
- 4. Create, optimise and publish: the planner continues in CAIRE scheduling and decides when to publish the plan.
- 5. Follow the result: an authorised partner can read the published plan, available analysis and status. Returning data to the source system requires support in the specific integration.
Three integration paths with different purposes
- Partner API: a customer or partner system calls CAIRE with a separate client and explicitly granted permissions for machine-to-machine reads and controlled requests.
- Carefox: inbound data for customers using Carefox. A planner reviews the import period, unit, people and scope before acceptance. Journals remain in Carefox.
- MCP: a person connects an AI tool using their own CAIRE sign-in. The tool receives only the data and actions permitted for that user and MCP server version. MCP is separate from a Partner API client.
What is each connected system used for?
- Carefox: use the customer’s existing operational input in CAIRE import and planning. Review the import before acceptance. Journals remain in Carefox; publishing a CAIRE plan changes nothing in Carefox.
- Fortnox, in development: base billing input on verified performed time rather than planned visit time. The intended workflow creates draft invoices only, for a person to review and approve. Customer and payer mapping and the complete invoicing workflow still require implementation and qualification.
- Phoniro, in development: the intended use is reported visit execution. Data scope, identifiers and verification must be established against the vendor API before use. A check-in or GPS location alone is not verified billable time.
- Quinyx, in development: the planned connection concerns staff roster shifts and absences. It does not include payroll or other financial staff data in Connect’s existing partner reads.
What can you do with Connect?
Available features depend on your agreement, connections enabled by the administrator and your permission for the units involved. Check the organisation’s settings before designing the customer workflow.
- Configure connections, partner clients, permissions and permitted units, and revoke access.
- Read permitted units, published plans and visits, clients, employees and skills. Resource reads can also include care plans, care decisions, roster shifts and absences when the required permissions are granted.
- Read available analysis and receipts to follow imported or applied input. Detail depends on the read view and data class; small cohorts may be suppressed in aggregated analysis.
- Submit cancellation and absence requests into the planner workflow. A submitted request is not an approved decision.
- Subscribe to permitted webhook events such as a changed request status or an available receipt.
- Open available analysis and plan views through a human sign-in. The delivered Connect views are read-only.
From partner input to planning
The extended partner catalog intake is under development and must not be treated as customer-ready until it is qualified and enabled. Its intended flow is: the partner submits bounded catalog input, a planner opens and reviews it in CAIRE, and Accept writes the reviewed input together with a receipt.
The planner checks unit, period, clients, employees, visits, shifts, addresses, identity conflicts and warnings. Accepting an import is separate from creating a schedule, optimising and publishing. An identical technical retry should return the same receipt; changed input must not reuse an idempotency key.
Requests and the planner’s decision
A cancellation or absence enters as a request with a status the partner can follow. A planner approves or rejects through CAIRE’s decision workflow. A partner can withdraw its own pending requests where withdrawal is supported.
Reschedule requests are under development: the partner supplies a preferred window, the planner approves or rejects it, and then moves the visit manually. Approval of the preference does not move the visit or start optimisation.
Getting started: administrator and developer
- Open Settings → Integrations. Check the organisation’s product access, activation and accepted data processing agreement for the intended use.
- Configure the customer connection and partner client. Select the responsible user, the minimum required scopes and an explicit permitted-unit list.
- Save the client secret when it is shown, using your approved secrets manager. Never place it in tickets, chats or source code.
- Use the OAuth and OpenAPI URLs shown for your environment. The actual server contract specifies fields, scopes, data classes, limits and responses.
- Start with a bounded test integration. Check successful and refused access, duplicate retries, revoked clients and event delivery before using it in a customer process.
Follow up, troubleshoot and revoke
Retain resource IDs, request IDs, status and receipts in your integration. A successful API response proves that call succeeded; separately check import acceptance, request decisions and publication.
For refused access, check client status, responsible user, product access, scopes and unit list. For duplicate calls, compare the idempotency key and body. For webhook problems, check endpoint, signature and delivery status. Log identifiers and closed error codes under your policy, not personal-data request or response payloads.
Revoke the client when it is no longer needed. Rotate secrets when required and follow your incident process. Include revoked access in the integration’s test flow.
What is still being developed?
Extended catalog intake with planner review, reschedule requests, further provider connectors, write-back and reconciliation are still being built. This is not a claim of deployed support or a completed standard integration with every vendor.
Quinyx, Phoniro and Fortnox integrations, record/retention flows and scaling require their own implementation and qualification. Carefox remains the journal system for Carefox customers. Customers without a journal system need an approved journal integration and responsibility model before journal data is handled.
Next steps for your organisation
Describe the system you use, the units involved, the data you need to read or submit, and what should happen after a planner approves the input. That defines the integration path and customer journey to verify.
Use the developer overview for Partner API, Carefox and MCP, and your environment’s OpenAPI contract for implementation. This guide describes the workflow; it does not replace granted access or the installed version’s contract.