Vad använder ni CAIRE Connect till?
CAIRE Connect är integrationsytan mellan CAIRE och kundens andra system. Den används för att dela rätt planeringsunderlag, läsa publicerade planer och analysresultat samt ta emot begäranden som en planerare beslutar om. Ni styr åtkomsten per organisation, anslutning, klient och enhet.
Ett exempel är att läsa in besöksunderlag från ett verksamhetssystem, granska det i CAIRE, skapa en plan och låta det andra systemet följa planens status. Ett annat är att visa en läsvy av analys eller plan i en partnerlösning. Integrationens omfattning bestäms av den version och de funktioner som är aktiverade för kunden.
Exempel från en vanlig arbetsvecka
- Planeraren: läs in en period från Carefox, granska brukare, besök och personal, och acceptera underlaget innan ett schema skapas. Syftet är att använda kundens befintliga underlag i CAIREs planering.
- Verksamhetschefen: använd tillgängliga analysresultat för att följa kontinuitet och tidsfördelning. Ett anslutet system kan läsa de resultat som har gjorts tillgängliga inom dess behörighet.
- Partnerutvecklaren: läs publicerade planer och besök inom beviljade enheter, följ begäransstatus och ta emot tillåtna webhook-händelser. Klienten får en avgränsad integration med kundens CAIRE-organisation.
- Användaren av ett AI-verktyg: anslut via MCP och fråga om enhetens planeringsläge, kontinuitet eller obemannade besök där motsvarande verktyg finns. Kontrollera förslag och fatta beslut i CAIRE.
Vad går in, vad kommer ut och vem beslutar?
- In till CAIRE via Carefox: det valda importflödets underlag för personer, omsorg och besök inom en vald enhet och period. Planeraren granskar omfattning och varningar innan Accept.
- I CAIRE: accepterat grundunderlag, ett daterat schema och ett löst planeringsresultat är separata steg. Import startar inte automatiskt optimering och publicering.
- Ut från CAIRE via Partner API: de publicerade planuppgifter, tillgängliga analyser och kvitton som klientens scopes, dataklasser och enhetslista medger. Kopplingen till Carefox är enkelriktad: CAIRE läser från Carefox men ändrar ingenting där.
- Begäran till CAIRE: partnern kan lämna en stödd begäran och följa status. Planeraren beslutar enligt arbetsflödet; en teknisk mottagningsbekräftelse är inte ett verksamhetsbeslut.
- Till ett AI-verktyg via MCP: de uppgifter som de anropade verktygen returnerar inom användarens behörighet. Välj ett AI-verktyg som organisationen har godkänt för uppgiften och den data som ska användas.
Ett konkret flöde: från underlag till publicerad plan
- 1. Välj källa och omfattning: administratören ansluter systemet och begränsar åtkomsten till rätt organisation, enheter och uppgifter.
- 2. Läs in och granska: planeraren väljer period och kontrollerar importens personer, besök, arbetspass och varningar i det tillgängliga importflödet.
- 3. Acceptera underlaget: planeraren godkänner vad som ska användas i CAIRE. Importen är ett eget steg med ett spårbart resultat.
- 4. Skapa, optimera och publicera: planeraren arbetar vidare i CAIREs schemaläggning och beslutar när planen ska publiceras.
- 5. Följ resultatet: en behörig partner kan läsa den publicerade planen, tillgängliga analyser och status. Återföring till källsystemet kräver stöd i den aktuella integrationen.
Tre integrationsvägar med olika syften
- Partner API: ett kund- eller partnersystem anropar CAIRE med en separat klient och uttryckligen beviljade behörigheter. Det används för maskin-till-maskin-läsning och kontrollerade begäranden.
- Carefox: en inkommande integration för kunder som använder Carefox. Planeraren granskar importens period, enhet, personer och omfattning innan underlaget accepteras. Journalerna stannar i Carefox.
- MCP: en människa ansluter sitt AI-verktyg med sin egen CAIRE-inloggning. Verktyget får bara den data och de åtgärder som användaren och den anslutna MCP-versionen har rätt till. MCP är inte samma sak som en Partner API-klient.
Vilka system används till vad?
- Carefox: använd kundens befintliga verksamhetsunderlag i CAIREs import och planering. Importen granskas innan den accepteras. Journalerna stannar i Carefox; en publicerad plan i CAIRE ändrar ingenting i Carefox.
- Fortnox, under utveckling: koppla faktureringsunderlag till verifierad utförd tid, inte planerad besökstid. Det avsedda flödet skapar endast fakturautkast som en människa granskar och godkänner. Kund- och betalarkoppling samt hela fakturaflödet behöver färdigställas och kvalificeras.
- Phoniro, under utveckling: avsikten är att använda rapporterade besöksutföranden som underlag. Exakt dataomfattning, identifierare och verifiering behöver fastställas mot leverantörens API innan funktionen kan användas. En incheckning eller GPS-position är inte i sig verifierad fakturerbar tid.
- Quinyx, under utveckling: den planerade kopplingen gäller personalens arbetspass och frånvaro. Den innebär inte att lön eller andra ekonomiska personaluppgifter ingår i Connects befintliga partnerläsningar.
Vad kan ni göra i Connect?
Vilka funktioner ni kan använda beror på ert avtal, vilka anslutningar administratören har aktiverat och er behörighet för de berörda enheterna. Kontrollera organisationens inställningar innan ni planerar kundflödet.
- Konfigurera anslutningar, partnerklienter, behörigheter och tillåtna enheter, samt återkalla åtkomst.
- Läsa tillåtna enheter, publicerade planer och besök, brukare, medarbetare och kompetenser. Resursläsningar kan också omfatta omsorgsplaner, omsorgsbeslut, arbetspass och frånvaro när rätt behörigheter är beviljade.
- Läsa tillgängliga analysresultat och kvitton för att följa vad som importerats eller tillämpats. Detaljnivån styrs av läsvyn och dataklassen; små grupper kan döljas i aggregerad analys.
- Skicka avboknings- och frånvarobegäranden till planerarens arbetsflöde. Skapad begäran betyder inte att planeraren har godkänt den.
- Prenumerera på tillåtna händelser genom webhooks, exempelvis ändrad begäransstatus eller ett tillgängligt kvitto.
- Öppna tillgängliga analys- och planvyer genom en mänsklig inloggning. De levererade Connect-vyerna är läsvyer.
Vilka data kan delas?
Connect ger inte generell tillgång till hela databasen. Först väljer administratören enheter och ändamål; sedan bestämmer klientens scopes och beviljade dataklasser vilka fält som kan returneras. Identitet, personuppgifter och hälsouppgifter behandlas som olika klasser.
- Enheter och planer: identifierare, planstatus, perioder och de publicerade planuppgifter som klienten får läsa.
- Brukare och besök: tillåtna identifierare och planeringsfält. Namn, adresser och koordinater kräver den personuppgiftsåtkomst som fälten anger. Planerad tid och rapporterad eller utförd tid är olika uppgifter.
- Medarbetare: tillåtna identifierare, personal- och kompetensfält samt arbetspass och frånvaro inom den beviljade omfattningen.
- Omsorgsplaner och beslut: endast de fält som kontraktet uttryckligen medger. Beslutsuppgifter kan kräva hälsodatabehörighet och särskild åtkomstloggning.
- Analys och kvitton: status, antal, period och tillgängliga analysmått; ett kvitto är ett spårbart resultat, inte ett bevis på att allt underlag är felfritt.
- Journaltext, fria orsaker, lön, ekonomiska uppgifter och omsorgsinstruktioner ingår inte i de befintliga allmänna partnerläsningarna. Utgå alltid från miljöns OpenAPI-kontrakt.
Så går underlag från partner till planering
Det utökade partnerintaget byggs nu och ska inte betraktas som en färdig kundfunktion förrän det har kvalificerats och aktiverats. Det avsedda flödet är: partnern skickar ett avgränsat katalogunderlag, planeraren öppnar det i CAIRE och granskar innehållet, och Accept skriver det granskade underlaget tillsammans med ett kvitto.
Planeraren kontrollerar enhet, period, brukare, medarbetare, besök, arbetspass, adresser, identitetskonflikter och varningar. Godkänd import är ett separat beslut från att skapa schema, optimera och publicera. En identisk teknisk omsändning ska ge samma kvitto; nytt innehåll får inte återanvända samma idempotency key.
Begäranden och vad planeraren gör
En avbokning eller frånvaro går in som en begäran med en status som partnern kan följa. En planerare använder CAIREs beslutsgång för att godkänna eller avvisa. Partnern kan återkalla sina egna fortfarande väntande begäranden där den åtgärden stöds.
Omschemaläggningsbegäranden är under utveckling: partnern anger ett önskat tidsfönster, planeraren bedömer och godkänner eller avvisar, och planeraren flyttar sedan besöket manuellt. Godkännande av tidsönskemålet flyttar inte besöket och startar ingen optimering.
Kom igång: administratör och utvecklare
- Öppna Inställningar → Integrationer. Kontrollera att organisationen har rätt produktåtkomst, aktivering och godkänt PUB-avtal för den avsedda användningen.
- Konfigurera kundanslutningen och partnerklienten. Välj ansvarig användare, minsta nödvändiga scopes och en uttrycklig lista med tillåtna enheter.
- Spara klientens hemlighet när den visas. Använd organisationens godkända hemlighetshantering; lägg den inte i ärenden, chattar eller källkod.
- Använd OAuth- och OpenAPI-adresserna som visas för er miljö. Den faktiska serverversionens kontrakt anger fält, scopes, dataklasser, begränsningar och svar.
- Börja med en avgränsad testintegration. Kontrollera både lyckade anrop och nekad åtkomst, dubbla omsändningar, återkallad klient och händelseleveranser innan en kundprocess använder integrationen.
Följ upp, felsök och återkalla
Spara resurs-ID, request-ID, status och kvitto i er integration. Ett tekniskt lyckat anrop säger att just anropet lyckades; kontrollera separat om importen accepterats, en begäran beslutats och ett resultat publicerats.
Vid nekad åtkomst kontrollerar administratören klientens status, ansvarig användare, produktåtkomst, scopes och enhetslista. Vid dubbla anrop jämför utvecklaren idempotency key och innehåll. Vid webhook-problem kontrollerar utvecklaren endpoint, signatur och leveransstatus. Logga identifierare och felkoder enligt er rutin, inte begärans- eller svarspayloadar med personuppgifter.
Återkalla klienten när anslutningen inte längre behövs. Rotera hemligheter vid behov och följ organisationens incidentrutin. Återkallad åtkomst ska också prövas i integrationens testflöde.
Vad är fortfarande under utveckling?
Utökat katalogintag med planerargranskning, omschemaläggningsbegäranden, ytterligare leverantörskopplingar, återrapportering och hantering av avvikelser mellan system byggs fortfarande. Dessa delar är inte ett löfte om driftsatt stöd eller ett färdigt standardavtal med varje leverantör.
Quinyx-, Phoniro- och Fortnox-kopplingar samt journal-/retentions- och skalningsflöden behöver sin egen implementation och kvalificering. För Carefox-kunder är Carefox fortsatt journalsystemet. För kunder utan ett journalsystem behöver journalintegrationen och ansvarsfördelningen beslutas innan journaldata hanteras.
Nästa steg för er verksamhet
Beskriv vilket system ni använder, vilka enheter integrationen gäller, vilka data ni vill läsa eller lämna och vad som ska hända efter att en planerare godkänt underlaget. Det gör det möjligt att välja rätt integrationsväg och verifiera kundflödet.
Använd utvecklaröversikten för Partner API, Carefox och MCP, och miljöns OpenAPI-kontrakt för den tekniska implementationen. Den här guiden beskriver arbetsflödet; den ersätter inte kundens beviljade åtkomst eller den installerade versionens kontrakt.