maica.
RFP response · OHC_0001
Opal Healthcare & Maica

Introducing Maica

Maica's response to Opal's request for proposal

Document nameIntroducing Maica
Document numberOHC_0001
Document date24 Aug 2026
Client organisationOpal Healthcare
Maica representativeAlex Hughes
Maica emailalex.hughes@maica.com.au

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.

1
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.
2
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.
3
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.
4
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.
5
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.
6
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.
7
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.
8
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.
9
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.
10
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.

Company overview and sector experience

Maica has been delivering innovative digital solutions to the Australian healthcare and community services sector for many years. Today, more than 12,000 users across Australia rely on the Maica platform to manage and deliver essential services. Our clients span a wide range of sectors, including direct support, community and transport services, support coordination, aged care, residential care, and supported independent living, among others.

Maica's parent company, Vertic, was founded in 2014 with a dedicated focus on supporting the nonprofit fundraising sector. Over the years, Vertic has partnered with many well-known organisations such as the RSPCA, Good Friday Appeal, and Save the Children, helping them achieve their missions through technology-driven engagement and data solutions.

Building on that experience and commitment to purpose-driven impact, Vertic transitioned into the healthcare and disability services sector in 2020, establishing Maica as a specialised solution built on the Salesforce platform. This transition was supported by our certification as an NDIS aggregator, allowing us to connect service providers, streamline participant management, and simplify compliance within a secure, scalable digital ecosystem.

Since then, our focus has remained clear: to empower care organisations with flexible, cloud-based technology that improves efficiency, compliance, and outcomes for the people they support.

Sector experience

Maica is a specialist Australian healthcare technology provider with a singular focus on the design, implementation, and ongoing optimisation of healthcare solutions. We do not operate in adjacent or unrelated industries; all of our capability, investment, and product development is dedicated exclusively to the Australian healthcare sector. This focus enables us to maintain deep domain expertise and remain closely aligned with evolving regulatory, funding, and operational requirements.

Maica has been delivering Salesforce-based implementations for over a decade, with the Maica platform itself deployed for more than five years across over 30 healthcare organisations. Our implementation experience ranges from small and mid-sized providers through to complex, multi-site organisations. Our experience spans both the NDIS and aged care sectors, with implementations supporting a wide range of service types and functional areas, including:

  • Direct support and community-based services
  • Residential aged care
  • Supported Independent Living (SIL)
  • Care coordination, rostering, and workforce management

This breadth of experience allows Maica to bring proven implementation patterns, sector-specific best practices, and risk-aware delivery approaches to each engagement. Clients benefit from a solution that is not only technically robust, but also operationally practical, compliant, and capable of evolving alongside their organisation.

Maica's scalability and flexibility

Maica, built natively on the Salesforce platform, extends the power of Salesforce by providing clients with a scalable and flexible framework to manage existing operations and seamlessly introduce new revenue streams. Leveraging Salesforce's cloud-native architecture, Maica enables organisations to configure, not code, allowing rapid deployment of new modules, workflows, and data models as business needs evolve.

The solution's scalability allows organisations to:

  • Add new service lines or programs without complex reengineering, using Salesforce's metadata-driven architecture
  • Automate new revenue processes through declarative tools such as Flow Builder and AI-driven insights
  • Leverage Salesforce AppExchange and APIs to integrate third-party systems, expanding functionality as operations grow
  • Utilise robust reporting and analytics for financial forecasting and performance tracking across multiple revenue streams
  • Scale securely, maintaining compliance and data protection through Salesforce's enterprise-grade security, permission, and audit controls

Many of Maica's clients successfully manage multiple organisational revenue streams within a single integrated Maica/Salesforce environment, for example combinations such as fundraising / NDIS / plan management, aged care / residential care / NDIS, and NDIS / community services / transport. Each program can maintain its own operational workflows, pricing structures, and compliance requirements, while leadership teams benefit from centralised reporting, unified dashboards, and real-time financial visibility across the entire organisation.

Implementation plan & structure overview

A live, shared plan

Maica's proposed implementation structure has been fully documented in a shared Jira project (user access details have been provided separately to this document) for your reference and review. An interactive summary of the plan is also available as a companion page to this document.

The following further details our intended delivery processes, which are informed both by our experience in delivering to the Australian healthcare sector and by your experiences shared with us during our discussions. We are very conscious that a digital implementation such as the one proposed here will benefit from sharing such experiences, aligning on goals, ways of working, and most importantly, connecting well as a team throughout.

Maica's implementation methodology is based both on taking into account your learnings and preferences as well as on an agile, sprint-based delivery model designed to deliver incremental value early, respond effectively to evolving requirements, and maintain continuous alignment with your organisation's priorities and operating environment. Rather than deferring outcomes until the end of the program, this approach enables functionality to be designed, built, reviewed, and refined in stages, providing early confidence and reducing delivery risk.

The implementation is delivered in close partnership with your team, with an emphasis on transparency, collaboration, and shared accountability. Regular ceremonies, including sprint planning, progress reviews, and demonstrations, ensure that decisions are well informed and that progress remains visible at all times.

The implementation plan

This sprint-based delivery model operates within a broader, structured implementation plan comprising eight interconnected phases and approximately 130 discrete work items, each with clearly defined deliverables and decision points.

The engagement commences with Project Initiation, which is fundamentally a listening exercise. Before any configuration takes place, we work with your team to review requirements in detail, validate the technical solution against them, and complete a transparent fit gap analysis. Early assessments of integration, data migration, security, and compliance are undertaken at this stage, and a benefits register is established so that the program remains anchored to measurable organisational outcomes rather than simply the delivery of software. In parallel, the implementation approach and business case are confirmed, including the delivery methodology, roadmap, cost benefit position, and commercial arrangements.

Project Planning represents the intellectual foundation of the program and is where we deliberately invest significant effort. Through in person workshops with your nominated stakeholders, we agree governance arrangements, ways of working, and a shared definition of success. From there, the complete solution definition is developed: detailed requirements, future state processes, functional and technical design, integration architecture, security and compliance design, and data governance standards. Critically, the more challenging conversations are also planned early, including the overall test strategy, the data migration and cleansing approach, organisational readiness and change impacts, and detailed cutover, rollback, and hypercare planning. In our experience, implementations rarely falter in the build; they falter when planning has been rushed.

Project Execution is where the solution takes shape, and it is here that the sprint model comes fully into effect. The technical build encompasses:

  • Core Maica claiming functionality
  • Integration between Maica and Dynamics 365 via Boomi
  • Salesforce core configuration within a single org architecture
  • Banking and receipting automation
  • AirDocs document integration
  • Automated identity and user provisioning

In addition, we have provided a number of optional development components, including Maica's Online Forms, Maica's Document Generation, and Maica's University online learning platform. We have also committed to developing the MAC portal integration directly into the Maica solution at no cost to Opal Healthcare.

Data migration is delivered as a series of iterative rehearsal cycles, with cleansing, transformation, and reconciliation at each pass, so that the production load holds no surprises. Testing is layered and rigorous, spanning unit, build verification, security, regression, performance and scale, and user acceptance testing conducted in the hands of your own people. Readiness activities for both organisations progress alongside the build.

Throughout the program, Project Governance and Control operates continuously. Status, risks, budget, scope, and quality are tracked and shared openly, Steering Committee meetings are properly prepared and supported, and defined decision gates ensure the program only proceeds with the agreed approvals in place.

Deployment and Go-Live follows a rehearsal first principle: the complete deployment, including data migration and solution activation, is executed in a full copy sandbox before being repeated in production, materially de-risking cutover. Go live is followed by a structured hypercare period with daily check-ins, rapid defect resolution, and honest reporting on adoption across your organisation.

Optional: extended dedicated hypercare

Beyond the standard hypercare period included in our core implementation, we offer an optional Extended Dedicated Hypercare service covering the first four months of live operation. In our experience, the true test of a billing and claiming implementation is not the day of go live but the month ends that follow, and this service is designed around exactly that reality.

A dedicated Maica hypercare lead acts as a single, consistent point of contact for your team throughout the period, triaging every issue and question, coordinating resolution, and managing a support cadence that is deliberately most intensive in the first weeks and tapers as the solution stabilises. The service provides hands-on support through your first four month-end claiming and billing cycles, covering claim generation and submission, billing runs, direct debit file production, receipting, and reconciliation against Dynamics 365, so that any issue is caught and corrected within the cycle rather than compounding into the next.

Alongside this, we continue resolving defects and stabilising the solution, monitor and reconcile the Boomi integration between Maica and D365, and support your people directly through scheduled office hours, targeted coaching, and short recorded walkthroughs of common questions. Progress is reported openly throughout, with a formal checkpoint at the end of each month reviewing stability and adoption against the agreed exit criteria, the final review forming the governed hypercare exit decision. This option represents an additional 87.5 days of effort, itemised in the effort appendix.

The program concludes with BAU Transition, encompassing formal knowledge transfer to your teams, finalisation of all documentation, handover of environment, security, and operational responsibilities, a governed hypercare exit decision, and complete financial and operational closure, including a post implementation review and an updated benefits register.

Our configuration philosophy

All implementations begin with Maica's native platform capabilities and established best practice processes as the baseline. Wherever possible, standard Maica functionality is configured to meet requirements, ensuring solutions remain scalable, supportable, and aligned with sector-wide learnings derived from years of implementation experience across the Australian healthcare, aged care, and disability sectors. This approach minimises unnecessary complexity, reduces long-term maintenance and upgrade risk, and ensures organisations benefit from ongoing product enhancements without extensive rework.

Where specific operational, regulatory, or organisational requirements cannot be met through standard configuration alone, Maica addresses these through carefully governed configuration, controlled customisation, or clearly documented manual or hybrid processes. All such extensions are assessed for impact, documented, and reviewed with stakeholders prior to implementation.

Sprint delivery framework

Whilst the overall implementation follows the phased structure described above, each sprint within this overall structure follows a consistent yet flexible sequence:

Define the functional focus

We collaborate with your team to agree on the specific business process or functional area the sprint will address, ensuring shared understanding of objectives, priorities, and success criteria.

Showcase Maica's native capabilities

We demonstrate how Maica's existing functionality supports the identified focus area, grounding discussions in real system behaviour and proven use cases.

Design the future-state process

Working together, we map the desired future-state process, aligning it with industry best practices while identifying opportunities to streamline workflows and maximise automation.

Identify solution gaps

We assess any gaps between standard functionality and the agreed outcomes, determining where additional configuration, custom development, or integrations may be required.

Develop and deploy enhancements

Identified improvements are implemented in a controlled staging environment, allowing for review, testing, and refinement before promotion to production.

Showcase and validate outcomes

Each sprint concludes with a demonstration of the completed work, validating that requirements have been met and confirming readiness to progress to the next phase.

This approach ensures that feedback is incorporated early and often, reducing delivery risk, supporting user adoption, and enabling informed decision-making throughout the project lifecycle.

The plan is estimated at between 500 and 750 person days of effort. This range is deliberate and reflects prudent contingency across design, build, and migration activities; it will tighten as discovery confirms key architectural decisions.

Ongoing support

All Maica clients receive comprehensive application support and regular product upgrades as part of their standard licence agreement. This ensures that every organisation consistently benefits from the latest platform enhancements, security updates, and regulatory changes, without disruption or unexpected additional cost. Upgrades are delivered in a controlled and considered manner, with a focus on maintaining system stability while progressively improving functionality and user experience.

Maica's dedicated support team provides responsive, knowledgeable assistance across both technical and functional areas. Our team understands the operational realities of healthcare service delivery and works closely with clients to resolve issues efficiently, minimise disruption, and maintain confidence in day-to-day operations.

Beyond standard application support, Maica offers enhanced or tailored support arrangements that evolve alongside an organisation's needs. Enhanced support services may include:

  • Dedicated client success and technical support resources
  • Scheduled solution health checks, reviews, and optimisation sessions
  • Minor configuration updates or incremental enhancements
  • Ongoing staff training, onboarding support, and refresher sessions
  • Integration monitoring, maintenance, and performance oversight

To formalise this long-term partnership, Maica offers an Ongoing Journey Agreement, which defines how we continue to work collaboratively with each client following implementation. This agreement provides a flexible framework for post-go-live support, optimisation, and enhancement, tailored to your preferred support model and organisational requirements. The Ongoing Journey Agreement ensures that Maica is not simply a system provider, but a long-term technology partner, committed to supporting stability, scalability, and continuous improvement as your organisation evolves.

Project management & governance

Clear communication and shared visibility are core to how Maica delivers projects. We believe that good governance is not about ceremony or paperwork; it is about ensuring the right people have the right information at the right time to make well informed decisions. Our governance approach is built on three foundations: a shared workspace that both teams can see at all times, a structured governance rhythm with clearly defined decision points, and communication practices that respect the time and working patterns of busy operational staff.

A single, shared workspace

We use Jira as our central tool for managing implementation activities, development work, and support requests. Jira is used to capture and track all key items including sprint objectives, requirements, configuration tasks, feature requests, and issues. Each item is prioritised and progressed in real time, giving both Maica and your team a clear, up-to-date view of what is being worked on, what is coming next, and what has been completed.

For this engagement, the complete implementation plan already exists as a structured Jira project, comprising approximately 130 individual work items organised across the eight delivery phases described earlier. Every item carries a plain language description of the work involved and an effort estimate, with estimates rolling up through each phase to provide a live view of scope and remaining effort at any level of detail. The project timeline is maintained in the same environment, meaning schedule, scope, and progress are never held in separate documents that can drift out of alignment; they are one and the same source of truth, visible to both organisations at all times.

When a change is proposed, its impact on scope, schedule, and effort can be assessed against the live plan rather than a static baseline, and once agreed, the plan is updated in front of everyone. Nothing is hidden, and nothing relies on memory.

Governance structure and rhythm

Alongside the day to day workspace, the program operates a defined governance rhythm. Project status is tracked and reported on a regular cadence, covering progress against schedule, budget position, risks and issues, and upcoming decisions. Risks and issues are maintained in a living register with named owners and agreed mitigations, and are reviewed openly rather than surfacing only when they have become problems.

Steering Committee meetings are held at agreed intervals, with papers, status summaries, and decision requests prepared in advance so that your executives' time is spent making decisions rather than receiving updates. The program also incorporates formal decision gates at key transitions, including solution design sign off, readiness to commence user acceptance testing, the go/no-go decision for production cutover, and the hypercare exit decision. Each gate has predefined criteria, and the program only proceeds when those criteria are genuinely met and the agreed approvals are in place.

Asynchronous, considered communication

To complement Jira, we regularly use Loom to share short, targeted screen recordings. These recordings are used to walk through new functionality, configuration changes, design decisions, or answers to specific questions. Loom allows your team to review updates at a time that suits them, which is particularly helpful for busy operational staff or teams working across different locations or time zones.

We have found this practice particularly valuable in healthcare and aged care settings, where the people whose input matters most are often the people with the least time to sit in meetings. A five minute recording reviewed between shifts frequently produces better feedback than an hour long workshop scheduled three weeks out, and the recordings themselves become a lasting reference library for training and support long after the moment has passed.

Working openly, together

Together, Jira and Loom support an open and collaborative way of working. Our aim is simple: at any point in the program, anyone at Opal Healthcare with an interest in the project should be able to see exactly where it stands, what is coming next, and why. In our experience, that transparency is the single most effective risk control an implementation can have.

Discovery & business analysis approach

Methodology philosophy

Overall, we believe that deep customisation and therefore technology debt should be minimised to the largest practical extent. We don't believe it is entirely avoidable as each organisation will have unique operational models and processes, but we do believe this can be contained substantially by offering an industry-specific solution. This is effectively what Maica is: it has been and continues to be developed based primarily on client input and feedback targeted exclusively at the Australian healthcare sector.

We also carry a 15-year mindset into everything we do; we believe a digital transformation such as this must yield this lifetime at the very least to be valuable and worth the investment being made. If decisions are short-term, they tend to fall apart quickly when legislative change comes through, staff change, or the sector more broadly changes. We want to make sure you are shielded from these events as much as can reasonably be expected.

Solution design approach

Maica's solution design approach is based on our proven assumption that the vast majority of typical requirements are met natively without the need for complex customisation. This has been shown to be true for your stated requirements also, as we have documented in our requirements sheet for your reference.

The requirements we care most about are the non-negotiables for you. These become our starting point to perform a gap analysis between these requirements and Maica's native feature set. We then use a number of mechanisms to collaborate with your team around potential solutions:

  • Interactive and transparent workshopping of ideas, freely discussing thinking, approach, shortcomings, risks, and benefits of each identified solution component
  • Prototyping where appropriate, using the Salesforce platform to quickly showcase what a solution component might look and feel like before a deeper investment is made
  • Maica application additions, in which we regularly adopt strong ideas that are common between multiple clients into the core Maica application at no cost to you

Our approach to solution design and delivery is intentionally iterative rather than strictly linear. Instead of completing the full solution design upfront, seeking a single approval, and then commencing development, we work collaboratively with you to design and deliver the solution in stages. We align early on a shared vision and target outcome, our common North Star, and confirm together that this direction is achievable. From there, we focus on delivering the solution in manageable, well-defined increments, each designed, reviewed, and validated with your team before progressing.

Solution design outcomes

As part of the solution design phase, all agreed design decisions, requirements, and assumptions will be documented in Jira as epics, stories, and associated acceptance criteria. These items will be made available to your nominated representatives for review, clarification, and formal approval prior to the commencement of any technical development activities. Following approval, the same tickets are used to manage and track delivery throughout the development phase, providing a single, auditable source of truth from solution design through to development, testing, and completion.

Data migration approach

Maica applies a structured, repeatable, and risk-managed approach to data migration, designed to ensure data accuracy, security, and integrity when migrating external data sources into Salesforce. The objective is to ensure that historical and in-flight data is migrated in a controlled manner, with full traceability from source to target, minimal disruption to business operations, and a high level of confidence in data quality post-migration.

Source systems and data inputs

Data is expected to be provided from external source systems in an agreed format, most commonly as CSV exports. Prior to migration, Maica works with the client to confirm source systems and data owners, data scope (objects, timeframes, historical depth), data volumes and file structures, and data quality considerations and known issues. All data extracts are versioned and stored securely to ensure traceability and repeatability throughout the migration lifecycle.

Source-to-target mapping

A formal source-to-target mapping process underpins the migration: identifying all source fields and datasets to be migrated, mapping each source field to its corresponding Salesforce object and field, defining transformation rules, default values, and conditional logic, and identifying mandatory fields, validation rules, and reference data dependencies. The mapping documentation is reviewed and approved by both Maica and client stakeholders prior to any migration activity.

Transformation and preparation

Following approval of the mapping, data transformation rules are applied to align source data with Salesforce data models and business rules, including cleansing and standardisation, normalisation of values, derivation of calculated fields, and handling of legacy inconsistencies. Prepared datasets are then validated for mandatory fields, data types and formats, referential integrity, and duplicates before being signed off as ready for migration execution.

Script development, sample load, and validation

Migration scripts are developed using Salesforce-approved mechanisms and industry-standard tooling, and are first executed in non-production environments to validate mappings, confirm record counts and relationships, resolve exceptions, and measure performance. A controlled production sample load follows, migrating a representative subset of data to validate end-to-end behaviour, confirm security and access controls, and enable business users to review migrated data in a live context. Following each migration run, Maica performs comprehensive validation including record count reconciliation, field-level spot checks, validation of key business processes and reports, and review of error logs.

Production load

Once validation is complete and approval is obtained, the full production load is executed in accordance with an agreed cutover plan, with monitoring and logging throughout, post-load validation and reconciliation, and controlled handover to business users.

Security and standards

Data security is a core consideration throughout: secure transfer and storage of extracts, restricted access to migration files and tools, role-based access controls within Salesforce, compliance with Australian privacy and data protection obligations, and secure deletion or archival of migration data following completion. Maica's approach aligns with ETL best practices, Salesforce data governance guidelines, agile delivery principles with staged validation, and the auditability requirements common to regulated industries.

Accredited migration execution

Maica uses an accredited data migration specialist to perform the actual migration execution, as required under our ISO 27001 certification to ensure data safety and privacy.

Hosting, security & compliance

Maica is hosted on the Salesforce platform, which operates as a Software-as-a-Service offering delivered through Salesforce's global, enterprise-grade cloud infrastructure. Salesforce data centres are designed for high availability, scalability, and resilience, with built-in redundancy across power, networking, storage, and compute resources. Where required, customer data can be logically segregated and hosted within specific geographic regions in accordance with data residency requirements.

Information security

Salesforce employs a comprehensive, defence-in-depth security model spanning physical, infrastructure, platform, application, and operational layers:

  • Physical security: strict data centre controls including 24/7 monitoring, controlled access, surveillance, and on-site security personnel
  • Network security: multi-layered protections including firewalls, intrusion detection and prevention, traffic monitoring, and DDoS mitigation
  • Platform security: continuous vulnerability scanning, penetration testing, and secure software development lifecycle practices
  • Encryption: data encrypted in transit using TLS and at rest using strong algorithms, with optional customer-managed encryption (Salesforce Shield) where required
  • Monitoring and logging: continuous monitoring of system activity with security event logging and alerting

Identity and access management

Salesforce provides robust identity and access management controls including role-based access control and permission sets enforcing least-privilege access, strong password policies, multi-factor authentication, integration with enterprise identity providers via Single Sign-On (SAML and OAuth), and detailed audit logs and login history to support monitoring and compliance reviews.

Data protection and privacy

Salesforce operates under a shared responsibility model: Salesforce secures the platform and infrastructure, while customers control data classification, access, and usage within the application. The platform supports logical separation of customer data, configurable retention and archival, secure backup and recovery, and tools to support data access requests, corrections, and deletions. Salesforce's privacy framework provides features to support compliance with Australian privacy obligations, including the Privacy Act 1988 (Cth) and the Australian Privacy Principles.

Compliance and certifications

Salesforce maintains a broad set of internationally recognised certifications and compliance attestations, independently audited on a regular basis, including ISO/IEC 27001 (information security management), ISO/IEC 27017 (cloud security), ISO/IEC 27018 (protection of PII in the cloud), SOC 1, SOC 2, and SOC 3 reports, and PCI DSS for applicable services. Compliance documentation is available through the Salesforce Trust site.

Business continuity and disaster recovery

Salesforce maintains formal business continuity and disaster recovery plans that are tested regularly. The platform is designed to withstand component failures without loss of service, and in the event of a major incident, established recovery procedures restore services within defined timeframes. Customers benefit from these controls without managing their own infrastructure-level disaster recovery arrangements.

Pricing breakdown

This section details our indicative pricing model for both licence and implementation. Maica's commercial approach to implementation is based on a capped time and materials model, which allows for greater control from your team over the activities, scope, and pace at which this implementation is executed.

Software licence investment summary

Maica licensing is based on the number of Salesforce users at the time of signing. For Opal, this is converted into an unrestricted site licence: a single organisation-wide fee under which access to Maica data no longer requires a specific licence to be assigned. This facilitates access to Maica data from external applications, integrations, and reporting functions without licence assignments or additional cost.

Maica maintains the solution's compliance with government regulatory and legislative change as part of the licence. Every change is analysed, built, and released by Maica at no cost to Opal.

IDSalesforce usersMonthly licence (ex GST)Basis
11,470 to 2,000$25,725.00Base price (list less 30%)
22,001 to 3,000$30,870.00Base price + 20%
33,001 to 4,000$33,442.00Base price + 30%
44,001 to 5,000$36,015.00Base price + 40%
55,001 and above$38,587.00Base price + 50%

Implementation investment summary

The implementation investment summary has been constructed using the proposed project structure, keeping in mind that parts of the project's technical details are yet to be determined. All costs are provided as a capped level of effort, meaning we will not exceed any listed costs (including stated tolerances) unless agreed to by Opal Healthcare. The proposal includes a dedicated and extended hypercare phase of 4 months, allowing for assistance and support throughout multiple billing cycles.

Implementation assumptions & exclusions

The following assumptions and exclusions apply to this document and implementation due to either insufficient details or a need for further clarification with your team.

Assumption / exclusionDescription
JiraThis implementation will be managed via Maica's Jira environment with a single assigned user from the client to have access to this project management solution.
TimelineAny delays by the client to provide the required details within the specified timeline do not change the invoice schedule and may incur additional costs.
Consulting ratesAny work performed under this Statement of Work will be charged at a daily professional rate of $1,700.00 per day (ex GST).
Scope statementAny scope not explicitly stated in this Statement of Work is considered out of scope and will be delivered using a time and materials commercial structure.
Solution architectureThe solution will be delivered within a single Salesforce org. Perceived performance issues reside in the ageing Dynamics platform rather than Salesforce, and a second instance is not considered necessary. Discovery will confirm the touch points between retained GEM processes and Maica processes within that one org.
Solution architectureMaica's native platform capabilities and best practice processes form the baseline; customisation is undertaken only where standard configuration cannot meet a confirmed requirement.
IntegrationMicrosoft Dynamics 365 remains the financial system of record, with integration between Maica and D365 delivered via Boomi. Opal Healthcare holds, or will procure, the required Boomi licensing and will provide access to appropriately skilled D365 resources for interface design and testing.
IntegrationDocument generation assumes Opal Healthcare retains AirDocs, and that existing templates can be submitted via API with generated documents returned via the same path. An alternative approach using Maica Docs can be provided, which avoids a ground up integration build and offers licensing cost control.
IntegrationBanking and receipting automation (BPay, direct receipts, credit card, Centrepay, direct debit files, dishonour matching) is estimated on an indicative basis; the target architecture is yet to be determined and estimates will be confirmed during solution design.
IntegrationAutomated user provisioning is dependent on confirmation of Opal Healthcare's HRIS platform. Effort for this component will be refined once the platform is confirmed.
Data migrationGEM is the primary migration source. Opal Healthcare will provide timely data extracts, access to source systems, and business owners to adjudicate data cleansing decisions. Migration effort assumes iterative rehearsal cycles with reconciliation at each pass.
Data migrationData quality remediation beyond the agreed cleansing rules (for example, systemic historical data issues discovered late) is subject to change control.
EnvironmentsOpal Healthcare will provide a full copy sandbox for the deployment rehearsal, refreshed from production ahead of that activity. The rehearsal includes production scale data migration where technically feasible.
TestingUser acceptance testing is executed by Opal Healthcare business users with Maica support. Opal will make suitable testers available for the agreed UAT window; test execution effort assumes the documented test scenarios and entry criteria are met.
ResourcingOpal Healthcare will provide timely access to subject matter experts, decision makers, and a nominated project lead. Steering Committee members will be available for the defined decision gates (design sign off, UAT entry, go/no-go, hypercare exit).
DeploymentGo live is a single cutover event, rehearsed in full in the sandbox beforehand, rather than a staged or site by site rollout. A staged rollout, if preferred, would require replanning of deployment and hypercare effort.
SupportHypercare operates for the agreed period post go live with daily check ins and defect resolution, concluding via a governed exit decision against predefined criteria, at which point the ongoing support model commences.
GovernanceProject governance effort is expended across the full program duration rather than as a sequential phase, and assumes the shared Jira workspace as the single source of truth for scope, schedule, and change control.
LicencesThird party costs (Boomi licensing, AirDocs, Salesforce licences, sandbox provisioning) are excluded from the effort estimate and borne by Opal Healthcare unless stated otherwise.

Additional information

Maica value-add responses

At Maica, we believe technology delivers the greatest value when it is built with deep sector understanding and real-world experience. Our software has been purpose-built for the Australian healthcare, disability, and community services sectors, and is backed by a team that has worked exclusively in this industry for many years. Through the combination of our Salesforce-based platform and our industry expertise, Maica provides clients with:

  • Purpose-built functionality: every feature within Maica has been designed around the workflows of healthcare and NDIS service providers, from budgeting and scheduling to compliance and reporting
  • Best-practice design: our implementation team brings years of hands-on experience with NDIS, aged care, and community health organisations
  • Continuous improvement: insights gained from our growing network of healthcare clients directly inform product enhancements, allowing all Maica users to benefit from collective sector learning
  • Scalable innovation: built on Salesforce, Maica gives clients the flexibility to grow into new service areas, add users or programs, and integrate with other systems as their organisations evolve
  • Trusted partnership: our team works as an extension of yours, combining technical expertise with empathy for the challenges faced by care providers and the people they support

In addition, Maica maintains a close partnership with the Salesforce team and has a long-standing history of collaborating to deliver comprehensive, future-ready digital solutions. Working as a unified team on your behalf, we focus on driving operational efficiency and value quickly and cost-effectively, while laying a strong foundation for sustainable growth.

Back to top ↑