Search by Profile

Jump to: Use Cases | Approach | API

---

A strength of the Profile Governed API approach is a server's capability to return only resource conformant to the governing profile. In the security use case, this is required (all responses must conform to an authorized profile).

Use Cases

The primary motivation for the Profile Governed API is to enable clients and servers to communicate using profile defined semantics. Technically, this requires the server to ensure that its communication with the client is in all cases conformant to the provided profile context. In practice this means:

1. Consistent Abstraction - Clients will generally use profiles (and collections of profiles/IGs) to govern their interactions with the server. These profiles encapsulate and abstract the specifics of the profile. For instance, a "HIE Patient" may be one with an included HIE identifier (slicing Patient.identifier by identifier.system and a min=1 slice for the HIE's identifier system). While in this case the search could be accomplished via normal search parameters (?identifier=http://hie.com/idsystem|) it would break the abstraction and require the client to parse the profile. In non-trivial cases, the profile may not be convertible directly to search parameters.
2. Profile based Authorization - Searches by a client are always limited by authorized profiles. For example, a client authorized only to read lipid panel observations (as defined by a lipid panel Observation profile) may only search within this context and the server needs a mechanism to enforce this policy at scale.

Approach

While the current validation machinery can perform this on an instance-by-instance basis, large scale validation of instance conformance to a new profile is daunting. We've approached this by:

1. Optimization based on pre-validated instances. We assume that all resources in our system are conformant to the HL7 definition, therefore we don't have to re-validate HL7 constraints. In a closed system, the acceptable profiles may be even tighter (an enterprise standard Patient may be common). These pre-validations are cached in both the positive and negative cases (this resources does not conform to profile X) to reduce the search space. In addition, background processes continually warm the validation cache for high-use profiles.
2. Parsing of profiles for "validation points" - constraints (min, max, maxLength, binding, constraint, etc.) that control whether an instance is conformant. Again, only validation points beyond the assumed minimum profile need be considered.
3. Conversion of validation points to search parameters where possible (fixed, binding, minValue[x], maxValue[x]).
4. Instance level validation of the post-search candidates (limited to a server defined maximum). Note that this validation can be optimized to only the remaining validation points - anything already guaranteed by a pre-validated profile or the search parameters need not be re-validated.

For the majority of our use cases where most restrictions are convertible to search parameters, these strategies allow us to evaluate profiles at a pace very close to our base search speeds. For complex profiles, performance degrades as complexity increases, and we limit the complexity of xpath/fluentpath constraints in searchable profiles (not all profiles are searchable).

API

Since search by profile is combined with predictable resource redaction, the _profile query parameter needs some additional modifiers.

Scenarios

Metadata profile search (as in STU3) - search for resources explicitly tagged with a profile in meta.profile. Redacted to the profile specified. This is the current behavior (excepting the redaction).

GET /Patient?_profile=http://example.com/my-precoordinated-profile

Evaluative Search - request that the server test all resources for conformance the specified profile and return matches (redacted to the specified profile). This is the most common use case.

GET /Patient?_profile:evaluate=http://example.com/my-brand-new-profile

Evaluative search without formatting - request the server evaluate all resources but not redact the results (assumes client rights to the un-redacted resource).

GET /Patient?_profile:no-format=http://example.com/my-brand-new-profile

Formatting only of search results - specify the formatting (redaction profile) of the results without affecting the members of the searchset.

GET /Patient?_profile:format=http://example.com/my-brand-new-profile

As per usual, these parameters can be combined for composite behavior. Here, find all resources conformant to one profile and return the results in the format of the second, probably a subset of the first.

GET /Patient?_profile:no-format=http://example.com/my-brand-new-profile&_profile:format=http://example.com/my-client-profile