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

Add deeper guidance to for Authorization and Authentication page

    XMLWordPrintableJSON

    Details

    • Type: Change Request
    • Status: Triaged (View Workflow)
    • Priority: Medium
    • Resolution: Persuasive with Modification
    • Specification:
      US CARIN Blue Button (FHIR)
    • Raised in Version:
      current
    • Work Group:
      Financial Mgmt
    • Related Page(s):
      Authorization Authentication and Registration
    • Grouping:
    • Resolution Description:
      Hide

      Change to:

      Security and Privacy Considerations

       

      General Considerations

      The CARIN Consumer-Directed Payer Data Exchange involves a patient’s claim and encounter information communicated through a member directed exchange. This data includes the Protected Health Information (PHI), Personally Identifiable Information (PII), and personal financial data. Members need to be able to direct the communication of this information through authenticated, authorized, and secure channels.

      Exchange of this information needs to be protected with proper security and privacy protections to avoid malicious or unintentional exposure of such information. All consumer-directed payer data exchanges must be appropriately secured in transit and access limited only to authorized individuals.

      Legal and Regulatory Requirements

      Implementers must ensure that APIs fully and successfully implement privacy and security features such as, but not limited to, those required to comply with HIPAA privacy and security requirements and other applicable law protecting the privacy and security of protected health information.

      Security Considerations and Guidance

      All implementers of the CARIN Consumer-Directed Payer Data Exchange Implementation Guide (IG) should follow the FHIR Security guidance, Security and Privacy Module, and the FHIR Implementer’s Safety Checklist guidance as defined in the FHIR standard where applicable and not otherwise superseded by this section of the IG.

      1. The FHIR Security specification provides guidance related to communication security, authentication, authorization/access control, audit, digital signatures, attachments, labels, narrative, and input validation. The FHIR security specification is available here.
      2. The FHIR Security and Privacy Module describes access control and authorization considerations to protect a FHIR server, how to document permissions granted, and how to keep records of performed events. The FHIR Security and privacy module can be found here.
      3. The FHIR Implementer’s Safety Checklist helps implementers be sure that they have considered all the parts of FHIR that impact their system design regarding privacy, security, provenance, and safety. The FHIR safety check list is available here.

      Security Requirements

      For the purposes of information exchange defined by this IG, additional security conformance requirements are as follows:

      Exchange Security

      1. The exchange of information SHOULD use the current version and SHALL use either current or the immediately prior release of Transport Level Security (TLS) as specified by the current release of NIST guidelines (SP 800-52).
      2. Implementers of this Implementation Guide SHOULD support SMART on FHIR Authorization best practices Transport Security section.

      Authentication and Authorization Requirements

      1. Implementations SHALL support the FHIR US Core Patient Privacy and Security requirements.
      2. Server systems SHALL publish their authorization and token endpoints for discovery in accordance with the SMART App Launch framework and publicly publish the Well-Known Uniform Resource Identifiers (URIs) JSON file with scopes defined in the scopes_supported property.
      3. Implementations SHOULD consider the SMART on FHIR Best Practices in Authorization found here.
      4. Server implementation SHALL support the following “SMART Core Capabilities” and MAY support additional capabilities:
        1. launch-standalone: support for SMART’s Standalone Launch mode
        2. client-public: support for SMART’s public client profile (no client authentication)
        3. client-confidential-symmetric: support for SMART’s confidential client profile
        4. sso-openid-connect: support for SMART’s OpenID Connect profile
        5. context-standalone-patient: support for patient-level launch context (requested by launch/patient scope, conveyed via patient token parameter)
        6. permission-offline: support for refresh tokens (requested by offline_access scope)
        7. permission-patient: support for patient-level scopes (e.g. patient Observation.read)
        8. permission-user: support for user-level scopes (e.g. user/Appointment.read)
      5. Server implementations of this Implementation Guide SHALL support, at a minimum, the following requested authorization scopes:
        1. openid
        2. fhirUser
        3. launch/patient
        4. patient/ExplanationOfBenefit.read
        5. patient/Coverage.read
        6. patient/Patient.read
        7. patient/Organization.read
        8. patient/Practitioner.read
        9. patient/Coverage.read
        10. user/ExplanationOfBenefit.read
        11. user/Coverage.read
        12. user/Patient.read
        13. user/Organization.read
        14. user/Practitioner.read
      6. MAY support the Security for Scalable Registration, Authentication, and Authorization 0.1.0 or later for registration of client applications and (authentication and authorization of client applications or users) a. If UDAP is supported, then all server systems and client applications that can protect private cryptographic keys and all systems of record SHOULD support UDAP JWT-Based Client Authentication for the authentication of client applications using asymmetric cryptography.

      Audit Logging and Provenance

      1. Audit logs and provenance are recorded.
      2. Server implementations SHOULD record IG related data access using the AuditEvent resource.
      3. Server implementations SHOULD support the ability to directly record and/or enable clients to assert (store) provenance associated with advance directive information using the Provenance resource.
      Show
      Change to: Security and Privacy Considerations   General Considerations The CARIN Consumer-Directed Payer Data Exchange involves a patient’s claim and encounter information communicated through a member directed exchange. This data includes the Protected Health Information (PHI), Personally Identifiable Information (PII), and personal financial data. Members need to be able to direct the communication of this information through authenticated, authorized, and secure channels. Exchange of this information needs to be protected with proper security and privacy protections to avoid malicious or unintentional exposure of such information. All consumer-directed payer data exchanges must be appropriately secured in transit and access limited only to authorized individuals. Legal and Regulatory Requirements Implementers must ensure that APIs fully and successfully implement privacy and security features such as, but not limited to, those required to comply with HIPAA privacy and security requirements and other applicable law protecting the privacy and security of protected health information. Security Considerations and Guidance All implementers of the CARIN Consumer-Directed Payer Data Exchange Implementation Guide (IG) should follow the FHIR Security guidance, Security and Privacy Module, and the FHIR Implementer’s Safety Checklist guidance as defined in the FHIR standard where applicable and not otherwise superseded by this section of the IG. The FHIR Security specification provides guidance related to communication security, authentication, authorization/access control, audit, digital signatures, attachments, labels, narrative, and input validation. The FHIR security specification is available  here . The FHIR Security and Privacy Module describes access control and authorization considerations to protect a FHIR server, how to document permissions granted, and how to keep records of performed events. The FHIR Security and privacy module can be found  here . The FHIR Implementer’s Safety Checklist helps implementers be sure that they have considered all the parts of FHIR that impact their system design regarding privacy, security, provenance, and safety. The FHIR safety check list is available  here . Security Requirements For the purposes of information exchange defined by this IG, additional security conformance requirements are as follows: Exchange Security The exchange of information  SHOULD  use the current version and  SHALL  use either current or the immediately prior release of Transport Level Security (TLS) as specified by the current release of NIST guidelines (SP 800-52). Implementers of this Implementation Guide  SHOULD  support SMART on FHIR Authorization best practices  Transport Security section . Authentication and Authorization Requirements Implementations  SHALL  support the FHIR US Core  Patient Privacy and Security requirements . Server systems  SHALL  publish their authorization and token endpoints for discovery in accordance with the SMART App Launch framework and publicly publish the  Well-Known Uniform Resource Identifiers (URIs)  JSON file with scopes defined in the  scopes_supported  property. Implementations  SHOULD  consider the SMART on FHIR Best Practices in Authorization found  here . Server implementation  SHALL  support the following  “SMART Core Capabilities”  and  MAY  support additional capabilities: launch-standalone : support for SMART’s Standalone Launch mode client-public : support for SMART’s public client profile (no client authentication) client-confidential-symmetric : support for SMART’s confidential client profile sso-openid-connect : support for SMART’s OpenID Connect profile context-standalone-patient : support for patient-level launch context (requested by launch/patient scope, conveyed via patient token parameter) permission-offline : support for refresh tokens (requested by offline_access scope) permission-patient : support for patient-level scopes (e.g. patient Observation.read) permission-user : support for user-level scopes (e.g. user/Appointment.read) Server implementations of this Implementation Guide  SHALL  support, at a minimum, the following requested authorization scopes: openid fhirUser launch/patient patient/ExplanationOfBenefit.read patient/Coverage.read patient/Patient.read patient/Organization.read patient/Practitioner.read patient/Coverage.read user/ExplanationOfBenefit.read user/Coverage.read user/Patient.read user/Organization.read user/Practitioner.read MAY support the  Security for Scalable Registration, Authentication, and Authorization  0.1.0 or later for registration of client applications and (authentication and authorization of client applications or users) a. If UDAP is supported, then all server systems and client applications that can protect private cryptographic keys and all systems of record  SHOULD  support UDAP JWT-Based Client Authentication for the authentication of client applications using asymmetric cryptography. Audit Logging and Provenance Audit logs and provenance are recorded. Server implementations  SHOULD  record IG related data access using the  AuditEvent  resource. Server implementations  SHOULD  support the ability to directly record and/or enable clients to assert (store) provenance associated with advance directive information using the  Provenance  resource.
    • Change Category:
      Correction
    • Change Impact:
      Compatible, substantive

      Description

       

      For as future STU2 consider more robust guidance.

      One example 

      https://build.fhir.org/ig/HL7/davinci-ehrx/security.html

      This is in addition to https://jira.hl7.org/browse/FHIR-31692
       

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            corey_spears Corey Spears
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: