Integration
Where the systems connect, and where they stand alone
NEXMAS and NEXCRM share one member record, and NEXCRM is embedded in NEXMAS if you opt for NEXMAS. NEXPHARM runs the counter on its own. NEXMAS and NEXPHARM both include a chronic register and are ready to verify member status, benefits and claim transactions online through biometric checks. NEXCRM reads member and claim activity from the health insurance administration backend you already run.
- Connected
- NEXMAS with NEXCRM embedded
- Standalone
- NEXPHARM at the counter
- Verification
- Biometric checks in NEXMAS and NEXPHARM
Who owns which record
A shared record only works when one platform or service is accountable for it. NEXMAS owns member identity and claims, NEXCRM owns interaction history, and NEXCRM reads administration activity from the backend you already run.
| Record | Source | What travels |
|---|---|---|
| Member identity | NEXMAS | Membership number, dependants, eligibility status |
| Claim records | NEXMAS | Submission, adjudication outcome, payment status |
| Interaction history | NEXCRM | Contact records, campaign membership, follow-up tasks |
| Chronic register | NEXMAS and NEXPHARM | Registered chronic conditions, authorisation status, repeat scripts and review dates |
| Biometric verification | Online biometric service, used by NEXMAS and NEXPHARM | Identity match, member status, benefit balance, claim transaction result |
| Administration feed for NEXCRM | Your medical administration backend | Member, claim and benefit activity read into profiles, segments and retention signals |
NEXPHARM keeps its own product, pricing and stock records inside the pharmacy system. It does not need NEXMAS or NEXCRM to operate. NEXCRM can be taken on its own or embedded in NEXMAS, and the chronic register in NEXMAS and NEXPHARM is maintained by the team that manages the chronic client.
Where the connections are
NEXMAS and NEXCRM
Member identity, claim history and service interactions sit on one profile shared by both platforms.
NEXCRM embedded in NEXMAS
Choose NEXMAS and the relationship layer is already inside it, so the service team works from the administration record without a separate deployment.
Chronic register in NEXMAS and NEXPHARM
Both platforms carry a chronic register, so chronic clients, their authorisations and their repeat scripts stay visible to the team managing them.
NEXMAS and NEXPHARM with online biometric systems
Member status, available benefits and claim transactions are confirmed in real time, so a provider knows the position before service is delivered.
NEXCRM and your administration backend
NEXCRM reads member, claim and benefit activity from the health insurance medical administration system you already run, so the relationship layer works from live records. NEXCRM does not perform biometric verification.
NEXPHARM on its own
The pharmacy system runs standalone, with no dependency on NEXMAS or NEXCRM and no shared record required.
Integration is configuration, not a separate product. Where an external system already holds a record, we connect to it rather than duplicating it.
Real-time verification
Member status confirmed before service, not after
NEXMAS and NEXPHARM are ready for integration with online biometric systems. A verification request confirms who the member is and what they are entitled to, so health providers work from the live position instead of a call to the scheme.
Member identified
A biometric check confirms the person at the counter or the provider desk is the member on the record.
Status and benefits confirmed
Membership status and available benefits are returned online, so the provider knows what is covered before treatment or dispensing.
Claim transaction checked
Any open or duplicate claim transaction is visible in the same response, which removes the rejection that arrives days later.
The same check runs at a pharmacy counter, a provider reception or a scheme service desk, which is what makes the process seamless for the provider and uneventful for the member. NEXCRM does not perform biometric verification: it reads member, claim and benefit activity from the health insurance medical administration system you already run, so the relationship layer works from the same live records.
Siloed operation compared with integrated operation
- One member record created once and used by administration and service teams
- Retention cohorts refreshed from live claims and interaction data
- Member status, benefits and claim transactions confirmed online in real time at the point of service
- Claim history and interaction history visible on the same member profile
- One chronic register inside NEXMAS and NEXPHARM, so chronic clients are tracked by the team that serves them
How a rollout usually runs
Start where the pain is
Deploy NEXMAS for scheme administration, or NEXPHARM as a standalone pharmacy system, with its own data migrated and validated.
Connect the relationship layer
Take NEXCRM on its own, or accept it embedded inside NEXMAS, so it reads membership, claims and interaction history from the administration backend onto one member profile.
Switch on real-time verification
Connect NEXMAS and NEXPHARM to an online biometric service so member status, benefits and claim transactions are confirmed at the point of service.
Discuss your integration requirements
Bring the systems and verification methods you already use. We will show which records we take over, which we connect to, and what the first phase looks like.