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

An IHE actor/transaction approach might make this section easier to read.

    XMLWordPrintableJSON

    Details

    • Type: Change Request
    • Status: Resolved - change required (View Workflow)
    • Priority: Highest
    • Resolution: Not Persuasive with Modification
    • Specification:
      SMART on FHIR (FHIR)
    • Raised in Version:
      2.0.0
    • Work Group:
      FHIR Infrastructure
    • Related Page(s):
      Overview
    • Related Section(s):
      1.6
    • Grouping:
    • Resolution Description:
      Hide

      Based on zulip discussion, we should improve clarity  / readability By

      1. separate out an "Overview" page from the main body of the App Launch specification. We'd include background, use cases, descriptions of the main actors, and the high-level sequence diagrams on this overview page, and leave the detailed protocol documentation on the remaining pages.
      2. Surface the "major steps" and actors of the authz process at the top of the detail page, including an explicit step for discover. For example (still to be agreed upon in a subsequent FHIR-I call) we'd call out steps like:
        1. App registers to obtain a client id
        2. App discovers a server's authorization capabilities
        3. App requests authorization (EHR or Standalone Launch)
        4. EHR evaluates the request, prompting end-user input
        5. App exchanges auth code for a token
        6. App uses the token to access the FHIR API
        7. App uses a refresh token


      FHIR-I Discussion

      Vassil notes: IHE uses "Transactions" as a higher level unit of specification, encapsulating (potentially) multiple messages

      Bas: we can explain steps like "EHR Launch" and "Standalone Launch" in terms of the actors involved

      Next week: Bas to bring a specific set of "major steps" to vote on

      Gino: As a meta point, we may want to avoid setting conventions "by proxy" (e.g., by pointing to conventions as established by IHE).

      Bas: Agreed; this is what I'm focused on specific examples here, not just "rewrite to match IHE".

      Show
      Based on zulip discussion , we should improve clarity  / readability By separate out an "Overview" page from the main body of the App Launch specification. We'd include background, use cases, descriptions of the main actors, and the high-level sequence diagrams on this overview page, and leave the detailed protocol documentation on the remaining pages. Surface the " major steps " and actors  of the authz process at the top of the detail page, including an explicit step for discover. For example (still to be agreed upon in a subsequent FHIR-I call) we'd call out steps like: App registers to obtain a client id App discovers a server's authorization capabilities App requests authorization (EHR or Standalone Launch) EHR evaluates the request, prompting end-user input App exchanges auth code for a token App uses the token to access the FHIR API App uses a refresh token — FHIR-I Discussion Vassil notes: IHE uses "Transactions" as a higher level unit of specification, encapsulating (potentially) multiple messages Bas: we can explain steps like "EHR Launch" and "Standalone Launch" in terms of the actors involved Next week: Bas to bring a specific set of "major steps" to vote on Gino: As a meta point, we may want to avoid setting conventions "by proxy" (e.g., by pointing to conventions as established by IHE). Bas: Agreed; this is what I'm focused on specific examples here, not just "rewrite to match IHE".
    • Resolution Vote:
      Carl Anderson / Bas van den Heuvel: 10-0-0
    • Change Category:
      Clarification
    • Change Impact:
      Non-substantive

      Description

      This section defines a series of messages between actors. An IHE like approach where the different request and response messages are explained separately will make this section easier to understand and implement.
      It will also make it easier to identify potential holes in the specification.

      I suggest that we reform the headings and content accordingly.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              bvdh Bas van den Heuvel
              Request in-person:
              Bas van den Heuvel
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Vote Date: