Jammjammjamm
commented
2 years ago You should be able to use user-level scopes for resources which aren't in the Patient compartment. If you encounter a problem when using user-level scopes for those resources, please let us know.
This is regarding ONC Certification (g)(10) Standardized API and a test on the Practitioner resource. It may not be an issue, rather open question/concern. As per test scenario, user-patient with scope patient/*.read shall be able to retrieve Practitioner resource. This scenario seems to contradict with some of the authorization aspects (or its particular implementations). It seems to me that Practitioner object should not be part of the patient clinical data and should not be returned as part of patient/*.read scope. Technical reason behind -- Practitioner object does not have reference to the Patient, hence when request to get Practitioner comes in (in user-patient context, with only patient ID known) it is not possible to verify if this particular patient is allowed to get practitioner (unless we pull up whole patient record and check its linkage). As an example, Observation has direct linkage to the patient ID and it is possible to verify if particular patientID should have access to it or not. FHIR specification is saying something similar per my understanding - https://www.hl7.org/fhir/smart-app-launch/scopes-and-launch-context.html#patient-specific-scopes - Patient-specific scopes start with patient/. Note that some EHRs may not enable access to all related resources (for example, Practitioners linked to/from Patient-specific resource
Very similar thoughts are actually applicable to the Organization resource as well.
Would appreciate any opinions on this. Are these test mandatory for the ONC certifications? How these data authorization concerns are supposed to be handled in general?
Thank you