Provider networks and connected-care ventures, with payer needs scoped separately
For digital healthcare ecosystems
Connect care journeys around shared patient and encounter context. Review clinical records, patient access and exchange needs together, then define interfaces and responsibilities for your network.
The supported use case
The supported use case is a provider network: several organisations on a shared model, with a defined patient record, an encounter record and agreed exchange with external systems. Payer-facing needs are scoped separately and are not assumed.
NXH One describes eight shared objects: Patient, Person and staff, Facility, Service and price, Encounter, Document, Action and CAPA, and Ledger and revenue. Care provides the clinical record, with separate Patient portal and Telehealth add-ons. Health data exchange uses FHIR R4 and HL7 v2, with acknowledgements retained.
Technical discovery checklist
- Which organisation owns the patient record and the encounter at each handover.
- Which interfaces are needed: FHIR R4, HL7 v2, or an exchange such as NABIDH, Malaffi or Riayati, and the licensing each one needs.
- Who is responsible for each connection, its permissions and its testing.
- Who reviews messages that are rejected or not acknowledged.
- How patients reach the service: Patient portal and Telehealth are separate add-ons.
- What any payer in the network needs, discussed as a separate scope.
Illustrative example: a referral between two providers
This example uses synthetic data. A clinic refers a patient to a hospital in the same network. Before any build, the teams agree who registers the patient, which record is the source for the encounter, what is exchanged and through which interface, and who follows up a message that is not acknowledged. The example shows the discovery questions, not a connection that already exists.
What this solution does not establish
NABIDH, Malaffi and Riayati are exchange contexts to discuss, not a promise that every site is connected. This solution does not establish national platform contracts, payer adjudication, universal exchange or an open marketplace of third-party services.
What you open with
A starting selection for your evaluation, not every feature in the chosen plan. Each module shows how it is bought, and a module marked as still being completed is not ready to deploy.
NextHealth Care
9 modules- Patient Registration CA-01 Included in Care Clinics, Care Clinics Pro and Care Hospitals.
- Scheduling & Appointments CA-02 Included in all three Care plans.
- Clinical Documentation & EMR CA-04 Included in all three Care plans.
- e-Prescribing CA-06 Included in all three Care plans; dispensing and ward administration depend on the relevant modules.
- Billing & Charge Capture CA-16 Included in all three Care plans; insurance claim processing is separately licensed.
- Medical Records Management CA-18 Included in all three Care plans.
- Patient Portal CA-20 Available as an add-on to any Care plan.
- Telehealth CA-22 Available as an add-on to any Care plan.
- Health Data Exchange CA-19 Applicable regulatory integration pack; available with any Care plan subject to confirmed scope and onboarding.
NextHealth Flow
1 modules- Document hub FL-07 Flow Documents is sold separately
Add each connection with a defined purpose
Begin with Care and the patient access capabilities required for your journey. Patient portal and Telehealth are separate add-ons, while health data exchange belongs to the regulatory pack where licensed. Use the interoperability page to review FHIR R4, HL7 v2 and the relevant exchange scope. Add Engage or Flow when the network also needs commercial handovers or operational follow-up. Each external connection still needs defined responsibilities, permissions and site-specific validation before it becomes part of an agreed deployment.
Common questions
-
No. Patient portal and Telehealth are separate Care add-ons. Select the capabilities the journey needs and review their scope rather than assuming portal access includes video consultation.
-
Care’s exchange scope includes FHIR R4 and HL7 v2 with acknowledgements retained. Review the actual resources, messages and site connection requirements before agreeing the interface implementation.
-
No. These exchange contexts require the relevant regulatory pack, licensing and implementation scope. Confirm the site-specific arrangements rather than assuming every exchange is enabled for every facility.
-
No national platform contract or government deployment is claimed. The page describes a product foundation and an evaluation route for connected-care requirements, not evidence of a public-sector award.
-
No payer adjudication capability is established by this solution. Care claims workflows support the provider context; a payer or network must review its own requirements separately before assuming that scope is available.
Not answered here? Contact the team
