CareTeam Profile¶
| Canonical | ../StructureDefinition/nexus-emr-core-careteam |
|---|---|
| Status | draft · 1.26.0 |
| Base | CareTeam (constraint) |
| Source | FSH · JSON |
Nexus EMR profile for CareTeam, capturing the care providers associated with a patient (e.g. most-responsible physician, nurse, midwife, referring physician). Backs the Patient Profile Care Providers section.
Access
What the endpoint offers¶
Declared for CareTeam by the capability statements this IG publishes. One row per statement; follow it for the rest of what that statement says about this type.
| Capability statement | Interactions | Search parameters |
|---|---|---|
| Server Capability Statement | read vread history-instance search-type create update delete |
patient status |
A cell reading none declared means that statement declares none, which is not the same as the endpoint having none. See how to read a capability statement for what a declared interaction and a declared search parameter do -- and do not -- promise.
SMART on FHIR scopes¶
CareTeam is reachable by a SMART on FHIR app. These are the scopes an app can request, and the platform permission each one resolves to.
| Request this scope | Grants | Permission required |
|---|---|---|
user/CareTeam.rs |
Read and search | careteam:read |
user/CareTeam.cu |
Create and update | careteam:write |
user/CareTeam.d |
Delete | careteam:delete |
user/CareTeam.cruds |
Everything above | careteam:read, careteam:write, careteam:delete |
CareTeam is in the FHIR patient compartment, so every suffix above also works with the patient context (patient/CareTeam.rs), which narrows the grant to the launch patient's records. The permission required is the same either way.
Reading the suffix¶
A clinical scope is <context>/<ResourceType>.<interactions>.
- Context is
patient(the launch patient's data only, and only for resource types in the FHIR patient compartment) oruser(everything the authenticated user may see, valid for any type). There is no system context. - Interactions are the letters
ccreate,rread,uupdate,ddelete,ssearch, written incrudsorder. Order does not matter on the way in:CareTeam.srandCareTeam.rsare the same scope. - The older SMART v1 suffixes still work and fold on arrival:
.readbecomes.rs,.writebecomes.cud, and.*becomes.cruds. - Wildcards (
patient/*.rs) expand over the SMART-exposed resource types only, never over everything this IG profiles.
Ask for a whole permission, or none of it¶
The platform has one read permission covering both r and s, and one write permission covering both c and u. A scope asking for half of either could only be granted by handing over more than it asked for, so it is refused rather than quietly widened: request CareTeam.rs, not CareTeam.r.
An unrecognised or ungrantable scope is rejected outright. It never silently resolves to an empty grant, which a caller could mistake for "no narrowing needed".