Repository navigation
Change Requests
This proposal is described here and is a composite of a set of change requests to follow (that will reference this as the header).
Essentially, this proposal is to set a guideline for servers to use profiles to govern their APIs to enable profile governed security and application access. This proposal:
- Allows implementers to constrain both instances and elements within instances to a particular profile for both read and write.
- Therefore defines a standard way for servers to communicate to clients precisely what will be returned in a payload and what may be submitted as a write.
- Therefore defines a standard way for a client to request a particular profile in its interactions with a server (read and write).
Use cases and details are here.
Current #8806
This proposal is part of the Profile Governed FHIR API tracker.
Currently, profile SHALL be more restrictive than their base profiles. This proposal relaxes that constraint by allowing the max property of an element definition to be smaller than its base when the SUBSETTED tag is added to the profile. This change allows implementers/specifiers to describe profiles for interchange that meet security and/or application needs, especially in the context of focused writes (PATCHes) to a resource.
Full justification is here specifically and in the broader document generally.
This proposal is part of the Profile Governed FHIR API tracker.
This change request affects the _profile search parameter.
TODO
This proposal is part of the Profile Governed FHIR API tracker. See that item for the larger context or the full proposal here.
This proposal define a set of rules for a server to follow when redacting a resource to be compliant with a given profile. Standardization ensures that clients can reliably interpret a server's response.
Known Use Cases:
- Bandwidth constrained clients may make very specific format/content requests of servers. If PATCH by Profile is implemented, this allows a client to read and write a minimized (focused) subset of resource elements.
- Information protection redaction can be negotiated between client and server in a predictable way. The server won't silently remove elements. It will inform the client they are only authorized to the elements in the given profile.
Proposed rules are:
- If the governing profile has SUBSETTED tagged, tag the resulting resource with SUBSETTED.
- Elements or element slices with max=0 are removed from the resource.
- Elements with max > 0 but not * are included if the instance has <= that number of instances. If the instance has more than max instances:
- If slicing is defined and ordered, include the first max number of instances.
- Otherwise, return an error (the server will not silently sample an un-ordered list).
This proposal is part of the Profile Governed FHIR API tracker. See that item for the larger context.
Predictable merging of a resource is required when a client writes a resource when it doesn't have rights (or desire) to update the entire resource. The problem space is shared with the PATCH operation in that the challenge is to discern the client's intent for the operation. This proposal sets that expectation.
A complete description of the proposal is at https://github.com/chrisgrenz/FHIR-Primer/wiki/PATCH-with-Profiles.
Merging is governed by these principles:
- Data provided by the client replaces equivalent data in the existing resource. Equivalence is:
- Element id (path+name) match for non-repeating elements or non-repeating slices.
- For non-discriminated lists, the entire list as a whole. This applies to repeating elements without a discriminator as well as instances not part of a named slice.
- Data known to the client (included in the profile) but not provided by the client is regarded as being removed by the client.
- Data not known to the client (not allowed in the profile) is a no-op and remains as is from the existing resource.