Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-39992

Repeated references to unknown "profile"

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Highest Highest
    • SMART on FHIR (FHIR)
    • 2.0.0
    • FHIR Infrastructure
    • (NA)
    • Hide

      The term "profile" is referring specifically to the app launch profile on OAuth 2.0; saying "this guide" would imply we're talking about the whole IG (backend services, token introspection, etc).

      We can clarify this when we introduce the term, by changing "This profile is intended to..." to say "This profile on OAuth 2.0 is intended to..."

      Show
      The term "profile" is referring specifically to the app launch profile on OAuth 2.0; saying "this guide" would imply we're talking about the whole IG (backend services, token introspection, etc). We can clarify this when we introduce the term, by changing "This profile is intended to..." to say "This profile on OAuth 2.0 is intended to..."
    • Josh Mandel/Rick Geimer: 17-0-0
    • Clarification
    • Non-substantive

    Description

      Throughout this section (and the Implementation Guide) repeated references are made to "this profile", "the profile", etc. Is it more accurate to refer to "this IG" or "this guide"; or is there truly only a single profile being discussed. I suspect that even if there is a single profile in the IG, that there's significant behavior required of various actors beyond communicating profiled content.

      Consider whether references to "profile" should be replaced with "guide" (or similar); or whether we need to more clearly indicate (perhaps in multiple locations) what it is we're profiling (OAuth 2.0?).

      Existing Wording:

      2.0.1 Profile audience and scope
      This profile is intended to be used by developers of apps..

      ...This profile does not dictate the institutional policies that are implemented in the authorization server.

      The profile defines a method through which an app requests authorization to access a FHIR resource, and then uses that authorization to retrieve the resource....

      Security mechanisms such as those mandated by HIPAA in the US (end-user authentication, session time-out, security auditing, and accounting of disclosures) are outside the scope of this profile.

      This profile provides a mechanism to delegate an entity’s permissions (e.g., a user’s permissions) to a 3rd-party app. The profile includes mechanisms to delegate a limited subset of an entity’s permissions (e.g., only sharing access to certain data types). However, this profile does not model the permissions that the entity has in the first place (e.g., it provides no mechanism to specify that a given entity should or should not be able to access specific records in an EHR). Hence, this profile is designed to work on top of an EHR’s existing user and permissions management system, enabling a standardized mechanism for delegation.

      (Comment 8 - imported by: Ron G. Parker)

      Attachments

        Activity

          People

            Unassigned Unassigned
            Rongparker Ron G. Parker
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: