Tests attempt to find a resource from the first search of each profile that matches the given scope(s), each scope is tested individually. After each scope has been checked, an attempt is made to find a resource that does not match any scopes. A read is performed on this resource, and should not be returned. Tests are skipped if any read cannot be populated from previous resources.
Testing Guidance
Added Spec tests that cover most cases. They behave as expected.
Running (US Core 7, Smart 2) against the reference server gives a 401, but I think that's a scope issue with the server -- by inspection:
The following request was made: https://inferno.healthit.gov/reference-server/r4/Condition/84ab26cd-e0ea-4c8f-90fd-eddd939f3d9b.
the read yielded:
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "processing",
"diagnostics": "Access to Resource Condition is restricted due to invalid scopes"
}
]
}
but this resource has a category value of encounter-diagnosis, so it should fit the scopes and be returned properly?
Summary
Added read tests for Granular Scope groups.
Tests attempt to find a resource from the first search of each profile that matches the given scope(s), each scope is tested individually. After each scope has been checked, an attempt is made to find a resource that does not match any scopes. A read is performed on this resource, and should not be returned. Tests are skipped if any read cannot be populated from previous resources.
Testing Guidance
Added Spec tests that cover most cases. They behave as expected.
Running (US Core 7, Smart 2) against the reference server gives a 401, but I think that's a scope issue with the server -- by inspection: The following request was made:
https://inferno.healthit.gov/reference-server/r4/Condition/84ab26cd-e0ea-4c8f-90fd-eddd939f3d9b
.the read yielded:
but this resource has a category value of
encounter-diagnosis
, so it should fit the scopes and be returned properly?The resource: