PACIO Transitions of Care Implementation Guide
1.0.0 - STU 1 US

PACIO Transitions of Care Implementation Guide - Local Development build (v1.0.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

## Security, Privacy, and Consent

Page standards status: Informative

All implementers of the LTPAC Transitions of Care (TOC) 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 TOC IG.

### General Considerations

LTPAC TOC information contains patient specific information, which means that it needs to be protected with proper security and privacy protections to avoid malicious or unintentional exposure of such information and must be appropriately secured in transit and access limited only to authorized individuals.

The LTPAC TOC IG focuses on providing a structure to share data and information. Policy, legal, and regulatory differences across states and local areas may impact the workflow and requirements associated with certain data types. Implementors should review the current context for where this IG is expected to be used to ensure those requirements are met.

#### Security Considerations and Guidance

All implementers of the LTPAC FHIR 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 LTPAC TOC 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 hot 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 safety. The FHIR safety check list is available here.

#### Security Requirements

For the purposes of Transitions of Care, additional security conformance requirements are as follows:

##### Exchange Security

1. The exchange of information SHALL support Transport Layer Security (TLS) Protocol Version 1.2 (RFC5246) or a more recent version of TLS for transport layer security.
2. Implementers of this Implementation Guide SHALL support SMART on FHIR STU 2.1 App Launch Framework and MAY support SMART on FHIR STU 2.1 Backend Services.
3. Implementers of this Implementation Guide SHOULD support mutually authenticated TLS.
4. Server implementations that expect to support browser-based javascript applications SHOULD enable Cross-Origin Resource Sharing (CORS) for REST operations. Many client web-based apps use javascript for API calls which requires CORS. However, CORS could present security concerns if not implemented correctly or is not continually updated as new security issues are found and addressed. Implementers of CORS SHOULD consider advice about CORS from sources such as Enable-CORS and Moesif blog on Guide to CORS Pitfalls.

##### Authentication and Authorization Requirements

###### SMART App Launch

The following only applies to servers supporting app launch:

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 STU2 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 STU2 Best Practices in Authorization
4. Implementation MAY support Health Relationship Trust Profile for User-Managed Access (HEART).

5. This guide defines the following server requirements for SMART on FHIR Core Capabilities:

   1. SHALL support Patient Access for Standalone Apps
   2. SHOULD support Patient Access for EHR Launch
   3. SHALL support Clinician Access for Standalone Apps
   4. SHOULD support: Clinician Access for EHR Launch
   5. In addition to the guidance above, there are additional requirements for other SMART on FHIR capabilities not included above, including:

      Element | Requirement | Reason
      --- | --- | ---
      sso-openid-connect | SHALL | Transitions of Care information is sensitive information, so authorization using SMART's OpenID Connect profile is required
      scopes | SHALL |
      openid: | Permission to retrieve information about the current logged-in user
      fhirUser: | Permission to retrieve information about the current logged-in user
      launch/patient: | When launching outside EHR, ask for patient to be selected at launch time
      patient/Patient.read: | Permission to read any resource for the current patient
      user/Patient.read: | Allows the client app to select the patient
      context-banner | SHOULD | The banner helps provides the patient context for the data
      permission-offline | SHOULD | Support for refresh tokens, which allow a session to be extended without repeated logins

###### SMART Backend Systems

The following applies to servers that support backend services:

1. Implementations SHALL support the SMART Backend Services: Authorization Guide

#### Privacy Requirement

For the purposes of Transitions of Care, privacy conformance requirements are as follows:

- Implementers SHOULD support data sharing policies with use of the Consent resource.

#### Provenance

1. Server implementations SHOULD support the ability to directly record and/or enable clients to assert (store) provenance associated with transitions of care information using the Provenance resource.