[Openid-specs-heart] Alice's health resource set

[Debbie Bucci]

Don't agree Adrian

a) ALL patient-level resources available as FHIR resources MUST also be
provided for registration with a HEART resource server even if the RS
decides to bypass the AS or override the AS authorization.

wouldn't - patient/*.read technically give you all patient resources
available by the FHIR server?


b) HEART MUST support data minimization in cases where ALL patient-level
FHIR resources are registered with an AS.

It's not HEART's responsibility to ensure data minimization as part of the
profile-  that sentiment could be covered by the  pre-conditions stating
that RS should; leverage the good work of the privacy principles standards.


c) Any resource server MAY choose to register sets of resources in order to
improve the user experience at the AS. These resources may or may not all
be specified by FHIR. These bundling and definition of these resource sets
may be done by HEART or by standards organizations like the HL7 DAF.

Perhaps agree with -- slight revision - A resource server MAY choose to
register sets of resources in order to improve the user experience at the
AS.   (perhaps include example(s) her



Looking at the Immunization resource, it references location, organization,
patient, practitioner and observation.
If you authorize only

patient / Immunization .read
on a GET  /Immunizations?patient=abc123    If I understand correctly ...
you get there reference to the resource If you want more than the reference
of the resource  - such as patient demographic information, would we need
to include the referenced resources scopes?
patient / Patient .read
patient / Practitioner .read
patient /organization.read
patient / observation .read
Are their conditional statements we can add to ensure additional info is
only on an _include or separate GETS/queries are related to the
immunization only?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160803/fd6d0832/attachment.html>