Primary Care Rostering / Attachment Modeling

Status: draft proposal. This is the Nexus EMR IG's chosen direction for primary-care rostering/attachment. It supersedes the former Group-based NexusEmrCoreRosterPanel model, which has been removed from this IG (both FSH and narrative). The FSH for the model below (the Patient.primaryCareAttachment extension) is now authored -- see src/fsh/extensions/PrimaryCareAttachmentExtension.fsh -- and this document remains the design of record. The extension and its status terminology are still draft while the IG stabilizes.

Summary

Model a patient's current primary-care roster/enrollment/attachment state directly on the FHIR Patient resource rather than introducing a separate roster or panel resource.

The model should distinguish two separate concepts:

Patient.generalPractitioner
    = provider clinically responsible for the patient in this EMR

Patient.primaryCareAttachment
    = provider(s) to whom the patient is formally enrolled / attached

These will often be the same provider, but they are not the same fact and must be able to diverge.

For a single clinic/EMR tenant, the evidence reviewed across Ontario, Alberta, British Columbia, Manitoba, and Québec supports:

primaryCareAttachment 0..1

primaryCareAttachment.providers 0..*
    normally 0..1
    >1 required for Alberta edge cases

An explicit Panel reference is not currently necessary.

Proposed Model

Conceptually:

Patient

generalPractitioner 0..1
    -> PractitionerRole

primaryCareAttachment 0..1
    providers 0..*
        provider -> PractitionerRole
        confirmedAt?

    status
    effectivePeriod?
    consentStatus?
    terminationReason?
    externalIdentifier?
    jurisdictionalStatus?

Example:

Patient.generalPractitioner -> PractitionerRole/Ben

Patient.primaryCareAttachment:
    providers:

      - provider -> PractitionerRole/Dave
        confirmedAt: 2026-01-15

    status: enrolled
    effectivePeriod:
      start: 2026-01-01

Meaning:

Local MRP / responsible provider: Ben
Formally enrolled provider: Dave

generalPractitioner and Enrollment Are Different Relationships

The key distinction is:

generalPractitioner
    Who is clinically responsible for this patient here?

primaryCareAttachment.providers
    To whom is this patient formally rostered/enrolled/attached?

Normally:

generalPractitioner = Dave
enrolledProvider     = Dave

But Ontario provides an important counterexample.

A patient may have a chart at Ben's clinic, with Ben acting as the local Most Responsible Provider, while remaining formally rostered to Dave.

generalPractitioner = Ben
enrolledProvider     = Dave

Dave may be:

• at another clinic;
• in another EMR tenant;
• using another EMR product entirely;
• not represented by a local user account.

The enrolled provider therefore needs to be modeled as a provider identity, not as a local EMR user.

This was explicitly confirmed in the discussion: there is still only one enrollment, but the enrolled provider may be different from the local MRP and may be remote.

Why Remote Enrollment Matters

In Ontario, particularly within Family Health Organizations, patients may be seen across multiple clinics.

A patient may be:

seen locally by Dr. Ben
formally enrolled to Dr. Dave at another clinic

Knowing that the patient is enrolled elsewhere within the FHO can matter operationally, particularly for billing and distinguishing an affiliated rostered patient from an unrelated walk-in.

However, this still represents:

ONE enrollment

not:

one local enrollment
+
one remote enrollment

The remote provider is simply the provider referenced by the patient's single formal attachment.

The Slack discussion summarized this as needing:

local provider assignment
+
one enrolled provider, possibly local or remote

Attachment Cardinality

One attachment per Patient

Within a single clinic/EMR tenant:

primaryCareAttachment 0..1

We have not identified a verified requirement in Ontario, Alberta, BC, Manitoba, or Québec where one Patient record must represent multiple distinct simultaneous formal attachment objects.

A patient may appear differently in multiple EMRs, but that is not the same thing.

For example:

EMR A believes:
    enrolledProvider = Dave

EMR B believes:
    enrolledProvider = Ben

That represents conflicting distributed state.

It does not imply:

Patient has two valid simultaneous enrollment objects.

This is a reconciliation/source-of-truth problem.

Provider Cardinality

Within the single attachment:

providers 0..*

For most provinces this is effectively:

0..1

Alberta is the important exception.

Alberta

Alberta CPAR supports unusual but legitimate cases where a patient can have more than one confirmed primary provider.

This includes shared panels where multiple providers jointly care for the same patient population.

Example:

primaryCareAttachment:
    providers:

      - provider: Smith
        confirmedAt: 2026-01-10

      - provider: Jones
        confirmedAt: 2026-02-15

This does not necessarily mean the patient belongs to two panels.

It may mean:

one shared panel
    providers:
      Smith
      Jones

Therefore Alberta drives:

providers 0..*

rather than:

primaryCareAttachment 0..*

This is an important distinction.

Do We Need an Explicit Panel?

Current recommendation:

No.

At least not as a universal patient-level concept.

We considered models such as:

primaryCareAttachment:
    provider -> Smith
    panel -> Panel123

and:

primaryCareAttachment:
    target -> Provider | Organization | Panel

But in the context of a single clinic/EMR tenant, we have not identified a concrete requirement where an explicit panel reference is necessary.

For ordinary provider attachment, a panel is effectively derivable as:

all patients attached to Provider X

For an Alberta shared panel:

all patients sharing the same provider set

Alberta does have real CPAR panel identifiers and panel-management concepts, but these are primarily provincial/interoperability/administrative concerns.

We have not found a normal requirement where, inside the same clinic and EMR instance:

Patient is attached to Smith

but

"Smith" is insufficient because Smith has multiple distinct
simultaneous panels that must be distinguished for that patient.

Therefore we should not introduce a first-class Panel resource until a concrete use case requires one.

Provincial panel identifiers, where needed for integration, can live in provider/clinic integration configuration rather than being repeated on every Patient.

Cross-Clinic / Cross-Tenant Panels

A patient may belong provincially to a panel associated with another clinic or EMR tenant.

That does not by itself require a panel reference in the local Patient record.

The local EMR may need to know:

enrolledProvider = Dave

even though Dave is remote.

That provider relationship is sufficient unless some business requirement specifically requires identifying the remote panel itself.

In Ontario, the important external fact is generally:

the patient is enrolled to Dr. Dave

not:

the patient belongs to remote Panel ID 78342

The discussion confirmed that there is only one formal enrollment, even when the enrolled provider is remote from the local clinic.

Provincial Fit

Ontario

Model:

generalPractitioner 0..1

primaryCareAttachment:
    providers 0..1

Example:

generalPractitioner = Ben
enrolledProvider = Dave

Dave may be local or remote.

There is only one formal enrolled provider at a time.

Ontario monthly RCX reconciliation may update roster state in large batches.

No explicit Panel resource is required.

Alberta

Model:

primaryCareAttachment:
    providers 0..*

Normally one provider, but multiple confirmed primary providers are permitted in legitimate cases.

Shared panels may contain multiple providers.

Provider-specific confirmation information may be required.

No evidence currently requires multiple attachment objects within one clinic/EMR tenant.

British Columbia

BC primarily centers attachment around the Most Responsible Provider.

Patients may appear on multiple provider panel lists because of stale, pending, or conflicting records, but this does not necessarily represent multiple simultaneously valid formal attachments.

The proposed model supports the current authoritative attachment without treating every conflicting panel appearance as a distinct attachment.

Manitoba

Patients are associated with one Home Clinic and one Most Responsible Provider.

This fits naturally into a single current attachment model.

No explicit Panel abstraction is necessary.

Québec

Québec supports:

individual attachment

or:

collective/group attachment

Group-level attachment may eventually require an Organization or similar target representation if needed.

It does not require a universal Panel resource.

Confirmation Date

Alberta introduces an important provider-specific attribute:

confirmedAt

This means:

the patient-provider relationship was actually confirmed on this date

It does not mean:

the Patient resource was last edited on this date

Therefore it should not be inferred from generic audit timestamps.

Because confirmation applies to an individual provider relationship, it belongs alongside the provider:

primaryCareAttachment:
    providers:

      - provider: Smith
        confirmedAt: 2026-07-20

      - provider: Jones
        confirmedAt: 2026-05-03

rather than:

primaryCareAttachment:
    providers:

      - Smith
      - Jones

    confirmedAt: ???

History, Audit, and Provenance

Do not explicitly model roster history arrays inside the Patient.

Avoid:

rosterHistory:

    - pending
    - enrolled
    - terminated
    - re-enrolled

Instead, require the FHIR repository/platform to maintain durable resource history.

Example:

Patient v1
    status = pending

Patient v2
    status = enrolled

Patient v3
    status = terminated

Patient v4
    status = enrolled

Repository/platform requirements should include:

durable resource version history
full historical reconstruction or diffs
updated-by tracking
auditability

This should be a general EMR platform requirement, not something reinvented specifically for rostering.

WellServices already tracks UpdatedBy and full entity diffs, allowing roster-state changes and their actors to be reconstructed. Medplum similarly maintains resource history.

Provenance and Source

FHIR Provenance or equivalent platform infrastructure should capture how and why a change occurred.

Useful distinctions include:

change mechanism:
    user
    automation
    import
    reconciliation

business source:
    Ontario MOH RCX
    clinic staff
    patient
    external EMR

technical actor:
    user-123
    rcx-import-service

These should not necessarily be collapsed into one generic source field.

Ontario RCX Reconciliation

Ontario roster/enrollment information may be updated rapidly in large monthly bursts during RCX reconciliation.

These should be normal updates to the Patient attachment state.

Example:

Before RCX:

Patient v12
    enrolledProvider = Dave
    status = enrolled

After RCX:

Patient v13
    enrolledProvider = Dave
    status = terminated

FHIR/resource history preserves the old value.

Audit/provenance records something like:

source = Ontario MOH RCX
mechanism = reconciliation
batch = July 2026 RCX
actor = rcx-import-service

There is no need to create a bespoke RosterChange domain entity solely to retain these transitions.

Dave specifically highlighted that RCX reconciliation creates large monthly bursts of changes and that source/history must be retained.

Why Not FHIR Group / List for Panels?

Earlier work and discussion identified several problems with modeling large rosters as explicit FHIR collection resources.

The Medplum recommendation quoted in the thread was to prefer a searchable property-driven model over large container resources because very large Group resources can become awkward operationally.

Previous experience also identified practical problems with large collection resources:

large updates become expensive

uniqueness checks introduce concurrency issues

membership mutations become operationally awkward

queries involving roster members plus other patient data
can require expensive joins or large numbers of requests

By contrast:

Patient.primaryCareAttachment.providers contains Smith

allows Smith's panel to be discovered through ordinary indexed search:

find all Patients attached to Smith

rather than maintaining a giant mutable collection of patient IDs.

This also aligns more closely with the EMR UX, where roster/enrollment status behaves primarily as patient-level state.

Proposed Final Shape

Patient

generalPractitioner 0..1
    -> PractitionerRole

    Local clinically responsible / MRP provider.


primaryCareAttachment 0..1

    providers 0..*
        provider -> PractitionerRole
        confirmedAt -> dateTime?

    status
    effectivePeriod?
    consentStatus?
    terminationReason?
    externalIdentifier?
    jurisdictionalStatus?

Typical Ontario:

generalPractitioner = Dave

primaryCareAttachment:
    providers:

      - Dave
    status = enrolled

Ontario remote-enrollment case:

generalPractitioner = Ben

primaryCareAttachment:
    providers:

      - Dave
    status = enrolled

Alberta shared-provider case:

generalPractitioner = Smith

primaryCareAttachment:
    providers:

      - provider: Smith
        confirmedAt: 2026-01-10

      - provider: Jones
        confirmedAt: 2026-02-15

    status = attached

Reading Enrolment Status (for consumers)

A consumer often just wants the boolean "is this patient enrolled here right now?" (this is the question the Daysheet raised). Collapse the primaryCareAttachment.status model as follows. The binding is extensible, so a consumer must also handle codes outside this list.

status = enrolled    -> currently enrolled  (Ontario-style formal enrolment act)
status = attached    -> currently enrolled  (Alberta shared-panel form of the SAME fact)
status = pending     -> NOT yet enrolled    (proposed/requested, not confirmed)
status = terminated  -> NOT currently enrolled (the attachment has ended)
status = not-enrolled -> NOT enrolled, by decision (deliberately not rostered -- distinct from absent/unknown)
status = fee-for-service -> NOT enrolled (seen fee-for-service; not rostered, not terminated)
status = <any other code> -> clinic-specific/custom status carried under the extensible
                     binding (consult the source value; do not assume enrolled)
no primaryCareAttachment present -> UNKNOWN / not recorded (NOT "not enrolled")

Guidance:

• For a plain "enrolled here?" flag, treat both enrolled and attached as true. attached is Alberta's shared-panel expression of the same underlying primary-care relationship, not a lesser state.
• not-enrolled, fee-for-service, and terminated are all "not currently enrolled" -- but they are decided negatives (a known non-enrolment), unlike an absent attachment (unknown). not-enrolled = deliberately not rostered; fee-for-service = seen fee-for-service, not rostered. Treat any code outside this value set (a source-custom status carried under the extensible binding) as "consult the source; do not assume enrolled."
• Do not infer "not enrolled" from an absent extension. Absent means the fact was never recorded; terminated means it was recorded and ended. Keep those distinct.
• To decide currently: a live attachment has status enrolled/attached and an effectivePeriod that has started and not ended. A terminated status (or an effectivePeriod.end in the past) means "was, is not now" -- use effectivePeriod.end for when.
• The provider a patient is enrolled to is primaryCareAttachment.providers[].provider (a PractitionerRole, possibly remote) -- not Patient.generalPractitioner, which is the local clinically responsible provider / MRP. See generalPractitioner and Enrollment Are Different Relationships.

Core Invariants

1. A Patient has at most one current primaryCareAttachment
   within a single clinic/EMR tenant.

2. generalPractitioner and primaryCareAttachment.providers
   represent different concepts.

3. generalPractitioner represents local clinical responsibility.

4. primaryCareAttachment.providers represents formal
   roster/enrollment/primary-care attachment.

5. The enrolled provider may be local or remote.

6. The enrolled provider does not need to be an EMR user.

7. providers is normally 0..1.

8. providers may be >1 because Alberta supports legitimate
   multiple-primary-provider/shared-panel cases.

9. Multiple providers do not imply multiple attachment objects.

10. No explicit Panel reference is required unless a concrete
    use case emerges where provider identity plus clinic/tenant
    context is insufficient.

11. Remote panel membership does not by itself require a
    remote Panel reference; the remote enrolled provider is enough.

12. Provider-specific business facts such as confirmedAt belong
    on the provider relationship.

13. Business facts must not be inferred from generic audit timestamps.

14. Historical state is supplied by durable FHIR/resource version history.

15. Audit and Provenance record who or what changed the state,
    why it changed, and where the information came from.

16. Conflicting claims across EMRs are source-of-truth and
    reconciliation problems, not reasons to create multiple
    attachment objects.

17. Large rosters/panels should generally be queried as sets of
    Patients sharing attachment properties rather than maintained
    as giant mutable FHIR Group/List membership collections.

Recommendation

Use a single patient-level primaryCareAttachment extension alongside Patient.generalPractitioner.

Keep the canonical model small:

generalPractitioner 0..1

primaryCareAttachment 0..1
    providers 0..*
        provider
        confirmedAt?

    attachment-level attributes...

Do not introduce an explicit universal Panel resource or panelId on Patient at this time.

Treat a panel primarily as a queryable set of patients sharing attachment characteristics, unless a future concrete requirement proves that panel identity itself has business meaning that cannot be derived from provider and clinic/tenant context.

Use durable FHIR repository history, audit, and provenance as platform-level infrastructure for change tracking rather than duplicating historical state throughout the clinical model.