+
+
+
+
+
+ 53 Privacy Consent on FHIR (PCF)
++ Privacy Consent on FHIR (PCF)) + Implementation Guide (Supplement). +
+
+
+
+
+
+
+
+ + Privacy Consent on FHIR (PCF)) + Implementation Guide (Supplement). +
++ later +
++ later +
++ Sharing of IPS (sIPS)) + Implementation Guide (Supplement). +
+Trial Implementation: Defined in PIXm
Trial Implementation: Defined in MHD
+Trial Implementation: Defined in PIXm
+Trial Implementation: Defined in XCPD
+Trial Implementation: Defined in PCF
+There are many security and privacy concerns with mobile devices, including lack of physical control. Many common information technologies use of HTTP, including REST, access far less sensitive information than health information. These factors present an especially difficult challenge for the security model. Application developers should perform a Risk Assessment during design of their applications, and organizations responsible for the operational environment should perform Risk Assessments on the design and deployment of the operational environment. See FHIR Security and Privacy Module http://hl7.org/fhir/R4/secpriv-module.html.
Actors should not communicate any patient information unless proper authentication, authorization, and communications security have been performed.
-There are many reasonable methods of securing interoperability transactions. These security models can be layered in without modifying the characteristics of the transaction. The use of TLS is encouraged, specifically the use of the Audit Trail and Node Authentication (ATNA) Profile. User authentication on mobile devices is encouraged using the Internet User Authorization (IUA) Profile. The IUA Profile is a profile of the OAuth protocol. IUA enables external Authorization providers, which can leverage pluggable authentication providers, such as OpenID Connect. The network communication security and user authentication are layered in at the HTTP transport layer and do not modify the interoperability characteristics defined in the transaction.
-Security audit logging (e.g., ATNA) is recommended. Support for ATNA-based audit logging on the mobile health device may be beyond the ability of the client-constrained environment. For example, the client actor may only support HTTP interactions using JSON encoding, while the Record Audit Event [ITI-20] transaction requires the SYSLOG protocol and XML encoding. For this reason, the use of ATNA Audit Logging is not mandated. This means that the organization responsible for the operational environment must choose how to mitigate the risk of relying only on the service side audit logging.
-Many transactions using HTTP REST will include query parameters that would be identifiers, quasi-identifiers, or sensitive health topics. For example, it is common for patient identifier to be a query parameter. With this URL pattern, the query parameters are typically visible in the server audit log or browser history. The risk from this visibility should be mitigated in system or operational design, by protecting the logs as sensitive data, or by designing other measures into the system to prevent inappropriate exposure.
+There are many reasonable methods of securing interoperability transactions. These security models can be layered in without modifying the characteristics of the transaction. The use of TLS is encouraged, specifically the use of the Audit Trail and Node Authentication (ATNA) Profile. User authentication on mobile devices is encouraged using the Internet User Authorization (IUA) Profile. The IUA Profile is a profile of the OAuth protocol. IUA enables external Authorization providers, which can leverage pluggable authentication providers, such as OpenID Connect. The network communication security and user authentication are layered in at the HTTP transport layer and do not modify the interoperability characteristics defined in the transaction.
+The Privacy Consent on FHIR (PCF) builds upon a basic Identity and Authorization model of Internet User Authorization (IUA) to provide consent-based access control. The Privacy Consent on FHIR is thus focused only on Access Control decisions regarding the parameters of the data subject (patient) privacy consent. The Privacy Consent on FHIR leverages these basic Identity and Authorization decisions as context setting for the authorization decision and enforcement. For example, a user that would never be allowed access would be denied access at the IUA level without invoking PCF, and where PCF will further evaluate authorization based on Privacy Consents.
+Security audit logging (e.g., ATNA, BALP) is recommended. Support for ATNA-based audit logging on the mobile health device may be beyond the ability of the client-constrained environment. For example, the client actor may only support HTTP interactions using JSON encoding, while the Record Audit Event [ITI-20] transaction requires the SYSLOG protocol and XML encoding. For this reason, the use of ATNA Audit Logging is not mandated. This means that the organization responsible for the operational environment must choose how to mitigate the risk of relying only on the service side audit logging. There is a Supplement to ATNA - Add RESTful ATNA (Query and Feed) that allows the use of FHIR AuditEvent and RESTful recording. The Basic Audit Log Patterns (BALP) Profile is available with general and reusable AuditEvent patterns for all of the FHIR RESTful actions.
+Many transactions using HTTP REST will include query parameters that would be identifiers, quasi-identifiers, or sensitive health topics. For example, it is common for patient identifier to be a query parameter. With this URL pattern, the query parameters are typically visible in the server audit log or browser history. The risk from this visibility should be mitigated in system or operational design, by protecting the logs as sensitive data, or by designing other measures into the system to prevent inappropriate exposure. The Basic Audit Log Patterns (BALP) Profile includes further and specific guidance.
IHE actors using FHIR will often use the OAuth 2 to authorize access to patient data. When an actor performs a transaction that includes an OAuth 2 authorization step and is grouped with an ATNA Secure Node or Secure Application Actor, it shall generate Audit events as specified in the IUA Profile in ITI TF-2: 3.71.5.1 Security Audit Considerations.
+IHE actors using FHIR will often use the OAuth 2 to authorize access to patient data. When an actor performs a transaction that includes an OAuth 2 authorization step and is grouped with an ATNA Secure Node or Secure Application Actor, it shall generate Audit events as specified in the IUA Profile in ITI TF-2: 3.71.5.1 Security Audit Considerations.
An application will often launch other applications (e.g., such as in the SMART on FHIR EHR Launch or Standalone Launch flows).
An application that is grouped with the ATNA Secure Node or Secure Application Actor shall generate audit events as specified in the following sections:
@@ -183,6 +184,7 @@When an actor launches an application, it shall generate an “Application Start” audit event that complies with the following pattern:
diff --git a/ITI/TF/Volume2/index.html b/ITI/TF/Volume2/index.html index f97684c35..4b42f9b76 100644 --- a/ITI/TF/Volume2/index.html +++ b/ITI/TF/Volume2/index.html @@ -813,6 +813,34 @@