关于FHIR资源字段读写策略及角色配置的技术问询

Great question! Let’s break this down clearly—FHIR doesn’t have native out-of-the-box support for granular field-level permissions, but you can absolutely build this using a mix of FHIR core resources and supplementary security tooling. And you’re right: CapabilityStatement (the updated name for CapabilitySystem in newer FHIR versions) isn’t meant for this—it only declares what the server can do, not who’s allowed to do what.

Where to Define Profiles in FHIR #

Profiles are formalized using the StructureDefinition resource. This is how you constrain or extend base FHIR resources (like ServiceRequest) to match your organization’s needs. For your scenario, you’d create two distinct StructureDefinitions:

• One that marks the authoredOn field as writable (e.g., ServiceRequest-AuthoredOn-Modifiable)
• Another that locks authoredOn to read-only (e.g., ServiceRequest-AuthoredOn-ReadOnly)

Profiles themselves don’t enforce permissions, but they give you a way to categorize resources that should follow different access rules. Your authorization logic can then check if the incoming request targets a resource conforming to a specific Profile and apply the right permissions.

Where to Define Roles in FHIR #

FHIR doesn’t have a dedicated "Role" resource, but there are two standard ways to model roles:

1. SecurityRole Resource (available in FHIR R4+): This resource is purpose-built for defining security roles, including their intended use, associated permissions, and linked users/groups. You’d use this to formalize roles like ServiceRequest-Clinical-Editor or ServiceRequest-ReadOnly-Viewer.
2. Group Resource: If you need to bundle users with shared permissions, you can use the Group resource to represent a role as a collection of individuals. You’d then map permissions to this Group in your authorization system.

Important note: Most of the actual permission enforcement happens in your authorization server (like an OAuth2/OIDC provider) or as custom logic in your FHIR server. FHIR servers typically rely on external authorization services to validate what a user/role can access.

Implementing Field-Level Write Control for authoredOn #

Here are practical, actionable ways to enforce your desired policy:

• Profile-Based Authorization Mapping: In your authorization server, set up rules like "Allow users with the ServiceRequest-AuthoredOn-Editor role to write the authoredOn field on ServiceRequest resources conforming to ServiceRequest-AuthoredOn-Modifiable". Your FHIR server would validate the user’s role, check the resource’s Profile, and block writes to authoredOn for unauthorized users.
• Custom FHIR Server Interceptors: Most open-source FHIR servers (like HAPI FHIR) support custom interceptors. You could write an interceptor that checks the authenticated user’s role, inspects the request payload, and rejects any attempt to modify authoredOn if the user isn’t in the allowed role.
• Security Labels: Use FHIR’s built-in security labels (via the meta.security element) to tag resources or fields that need restricted access. Your authorization policy can then allow write access to authoredOn only for users who have permission to interact with that specific label.

Key Takeaway #

FHIR gives you the building blocks (StructureDefinition for Profiles, SecurityRole/Group for roles) to model your access control requirements, but enforcing field-level permissions requires integrating with an authorization server or adding custom logic to your FHIR server. CapabilityStatement is just for advertising server capabilities—not enforcing security rules.

内容的提问来源于stack exchange，提问作者Joe Taras