maica.

Technical solution · Opal Healthcare

Opal Healthcare & Maica

Technical solution overview

The ten components of the proposed architecture, and why a single Salesforce org is the right home for all of them

The technical solution

This section describes the proposed technical solution including all required and optional components. Each entry corresponds to the numbered components within the solution architecture, detailing the specific functionality, the intended integration pathway, and the strategic justification for its selection within the broader technical framework.

GEM CRM (Salesforce) with Maica

Retained · single org

Application

Opal's current GEM CRM, implemented on the Salesforce platform and serving as the system of engagement for the resident journey. Maica will be installed into this same Salesforce org as a managed package as part of the implementation.

Integration

Native. No integration build is required between GEM and Maica; both operate on a shared Salesforce data model within a single org, with Maica configured against shared objects such as accounts and contacts.

Comments

A separate Salesforce org was discussed during discovery. Following review of the session notes and validation that the performance issues raised relate to the AX 2009 platform and not Salesforce, our firm recommendation is a single org, keeping the entire solution in one environment and removing an integration layer entirely. A summary of the single org versus two org assessment is provided in this section.

Services Australia

Packaged Maica integration

Application

Maica's packaged, secure, API-driven integration with Services Australia. Handles the synchronisation of care recipient data, including the full funding and assessment profile, and the finalisation and submission of accommodation balances and claims through the ACWS / B2G aged care channels.

Integration

Native to the Maica package. Delivered, maintained, and kept compliant by Maica as part of the platform; no integration build is required by Opal.

Comments

Maica maintains this integration against government regulatory and legislative change as part of the licence, with every change analysed, built, and released by Maica at no cost to Opal.

My Aged Care (MAC portal and GPMS)

Roadmap · no cost

Application

A future state integration with the My Aged Care provider portal, implementing the available suite of APIs covering referrals, assessments and related data flows, together with an integration to the RN API enabling 24/7 registered nurse data to be posted to GPMS (the Government Provider Management System).

Integration

API-driven, per the MAC portal API suite. Inbound: referrals, assessments and other flows made available under the MAC portal APIs. Outbound: RN reporting data to GPMS via the RN API.

Comments

This integration was not scoped in the RFP, nor requested in any future state requirement by Opal. It is on the Maica product roadmap, and we are offering it at no cost to Opal as it will be added to the Maica package. We will commit to aligning its delivery to the project timeline so it lands within the overarching programme of work. The detail will be expanded once government API documentation is available.

Boomi

Retained

Application

Opal's incumbent middleware and integration layer, currently sitting between Salesforce and Dynamics 365. Opal has indicated a preference to retain this architecture, so Boomi will serve as the middleware for the new Maica to Dynamics 365 integration.

Integration

Middleware. Boomi processes will carry finance data between Maica (Salesforce) and Dynamics 365, in both directions, as described in element 5.

Comments

Because the integration will map net new objects and fields, we expect the Boomi processes themselves to be new builds rather than reuse of existing mappings. Discovery to determine what existing integration surfaces and patterns can be reused as part of the programme.

Dynamics 365

Retained · new integration build

Application

Opal's current ERP and finance package. This integration covers the flow of financial data between Maica and Dynamics 365 in both directions, via the retained Boomi middleware (element 4).

Integration

Bidirectional, via Boomi. Outbound from Maica: invoices and invoice line items, payments (including settled direct debit transactions where Maica manages the direct debit call-out and receives the transaction confirmation), lump sum transactions, and accounts representing accommodation balances. Inbound to Maica: payments (for example bank payments reconciled in the ERP), refunds applied against existing invoices, and invoice and line item data for recharges and procurement items (vendor invoices split and applied to residents). Contact and account synchronisation between the platforms, primarily represented as debtors.

Comments

Payments flow in both directions by design: where Maica initiates and settles a transaction (such as direct debit), the settled payment is sent down to the ERP; where payment is received and reconciled in the ERP (such as bank payments), it flows back into Maica. Refund and recharge flows return to Maica because they must be communicated to the resident through statements and document generation. Final object-level scope will be confirmed against the list of records, objects and processes to be provided by Opal.

Microsoft Teams (via custom MCP server)

Optional · costed

Application

An optional piece of proposed architecture: the development of a custom MCP server sitting between Maica (Salesforce) and Opal's internal communications platform, Microsoft Teams. This provides a headless integration method from Teams directly into Salesforce, allowing privileged users to gain data insights through chat prompts from within Teams.

Integration

Custom MCP server. Conversational, headless access from Teams into Salesforce data. Extensible to allow users to interact with data, including invoking processes directly from chat commands within Teams.

Comments

All access is governed by the querying user's own Salesforce permissions, so users can only ever see data they are already authorised to access. As Opal already operates several help bots and chat channels, this capability can be surfaced through an existing front door rather than introducing a new destination for staff.

HR system (HRIS, to be confirmed)

New build · in scope

Application

A limited, one-way integration from Opal's HRIS platform into the solution in the form of an automated user provisioning flow.

Integration

One-way, inbound. When defined criteria are met on the HR platform (for example at point of hire), the integration triggers the creation of a user and the assignment of the relevant permissions, permission sets and roles within the platform.

Comments

Driven by Opal's scale: with a workforce of more than 22,000 team members and growing, manual account creation is not viable, and the requirement is for no humans in the loop. Maica ships with permission sets that can be extended as the starting point for role-based access. HRIS product name to be confirmed.

Maica University (LMS)

Optional

Application

An optional piece of proposed architecture: the use of Maica's University LMS platform for training materials and user onboarding for Maica, with the option to customise and extend the available content for Opal's broader onboarding and training use cases.

Integration

Native integration with Salesforce. Maica University can write attributes back against a resource record, for example on completion of LMS modules, enabling training completion to be tracked within the platform.

Comments

Maica University ships with a full Maica content suite and supports customer-authored modules, allowing Opal to extend it beyond the Maica solution to the wider transformation if desired.

AirDocs

Decision point · alternative to 10

Application

Opal's incumbent document generation solution, used primarily for the generation of fee statements and other documents issued to residents and care recipients. The current architecture integrates AirDocs with a Microsoft database, so this would be a net new integration build to push the relevant data directly from Salesforce.

Integration

New API integration, bidirectional. Outbound: statement and document data payloads sent from Salesforce to AirDocs for dynamic document assembly. Inbound: generated documents returned and attached to resident records in Salesforce. Distribution (email and post) continues to be handled within AirDocs.

Comments

Opal's RFP confirms this pattern is supported: AirDocs has advised that in a cloud environment the local portal is not required and data can be sent directly from the source solution via API, and Opal has stated the expectation that the new solution replicates the current data-send information into direct APIs. This element and element 10 are presented as alternatives for Opal's decision.

Maica Apps

Recommended alternative to 9

Application

The alternative to element 9: Maica's native document generation, forms and portals platform, covering Maica Docs (fee statements and documents), Maica Forms (web forms) and Maica Portals (client access).

Integration

Native. These capabilities are natively integrated with Salesforce, including the ability to write back to records from features such as eSignature. No integration development is required.

Comments

We see significant savings for Opal in moving from AirDocs to Maica Apps, and regard this as the path of least resistance: no integration build is required, with effort limited to the recreation of Opal's document templates and forms on the Maica Apps platform. Elements 9 and 10 are presented as an either/or scoping decision for Opal; our recommendation is Maica Apps on cost and simplicity grounds.

Single versus multiple Salesforce organisations

During discovery, the option of implementing Maica in a separate Salesforce org, held at arm's length from the GEM CRM with integration between the two, was discussed.

There are genuine arguments for a separate org: it offers a clean implementation of Maica into a brand new environment, allows the application to be stood up more quickly, enables data migration to be performed with much lower risk of impacting BAU operations, and simplifies go-live by keeping the new solution siloed until cutover. However, we consider the arguments against it to be more significant.

A two-org model would require duplicate databases of customer data to be maintained and synchronised across both environments, a material and permanent overhead given how much of the client journey lives within the GEM CRM, and it introduces an entire integration layer that a single org model removes. The deciding factor is performance. Having reviewed the discovery discussion, the platform performance issues Opal described sit within the AX 2009 environment, not Salesforce; Opal is not experiencing Salesforce performance problems today, so a new org would not resolve the pain point that originally motivated the discussion.

Our recommendation

House everything within the single existing Salesforce org, with performance safeguarded through the full copy sandbox, scale testing and month-end performance testing approach described in this proposal.