Da Vinci Health Record Exchange (HRex), published by HL7 International / Clinical Interoperability Council. This guide is not an authorized publication; it is the continuous build for version 1.2.0-snapshot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-ehrx/ and changes regularly. See the Directory of published versions

Security and Privacy

Page standards status: Trial-use

Highlight text changes?

The following content is intended to apply to all Da Vinci IGs. IGs derived from HRex SHOULD all reference this section, though they can qualify and supplement the content here as appropriate for the specific technologies they are using, and the threat environment and privacy considerations involved in their specific use case. ^§sec-1

Statutes, Regulations, and Guiding Principles

1. All implementations of any Da Vinci FHIR Implementation Guides (IG) SHALL meet all current relevant Federal and State statutes and regulations regarding security and privacy. ^§sec-2

2. All IGs SHALL use applicable technical standards required by current regulations published by the Centers for Medicare and Medicaid Services (CMS) and the Assistant Secretary for Technology Policy and Office of the National Coordinator for Health Information Technology (ASTP/ONC) (allowing for voluntary use through the SVAP) unless an exception has been granted. ^§sec-3

3. All IGs and implementations SHOULD follow the current Da Vinci Guiding Principles. ^§sec-4

4. All IGs and implementations SHALL support patient/member consent and/or treatment of sensitive information consistent with Federal and State statutes and regulations. ^§sec-5

5. All IGs and implementations SHOULD support the consent and data sharing policies of trading partners involved in the exchange that are more protective so long as policies are consistent with or more restrictive than Federal and State statutes and regulations. ^§sec-6

FHIR Clinical Safety, Security and Implementation Guidance

All FHIR Implementation Guides SHOULD follow the FHIR Security guidance and FHIR Implementer's Safety guidance as defined in the relevant FHIR specification (e.g. Release 4.1.0) where applicable and not superseded by this Section or specific IG requirements. ^§sec-7

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 Implementer's Safety specification is a check-list to help 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/Privacy Related Technologies Including Explicit Consent and Security Labels

1. While past ASTP/ONC regulations did have optional rules for data labeling and consent directives, as of May 2020, ASTP/ONC has elected to not establish rules for either data labeling and consent directives as part of the Final Rule for the 21st Century Cures Act.

2. At present there is no explicit regulatory requirement for the use of these technologies in Da Vinci specifications.

3. However, to meet the statutes, regulations, and guiding principles above, consent directives and security labels MAY be considered and used. ^§sec-8

4. Organizations which plan to take advantage of these additional capabilities are responsible for negotiating support for these mechanisms between trading partners. The FHIR implementation guide defining the recommended standard is the FHIR Data Segmentation for Privacy IG.

Exchange Security

• When exchanging Protected Health Information (PHI) between entities, the exchange 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 National Institute of Standards and Technology (NIST) guidelines (SP 800-52). ^§sec-9 TLS SHALL be implemented as per RFC8705. ^§sec-10

• When using OAuth (either through SMART or UDAP), OAuth tokens issued SHALL be tied to the client system's certificate. ^§sec-12

When mutual TLS is used, it SHALL be done in accordance with RFC8705 ^§sec-13 There are certain constraints on this RFC that apply across all Da Vinci IGs:

• The TLS authorization mechanism SHALL be PKI-Mutual TLS (i.e. not self-signed certificates) ^§sec-14

• Signing options SHALL use URIs, not DNS, IP, email, etc. ^§sec-15

• If mutual TLS is used with OAuth, the OAuth tokens SHALL be bound to the client system's certificate (and are therefore not shareable) ^§sec-16

Note: There is ongoing work to enhance the capabilities of the above specifications to ensure a more secure exchange that recognizes issues related to fine grain scopes.

Additionally Protected Information

Additionally protected information can include items defined by Federal (e.g. 42 CFR Part 2), State (e.g. many states protect substance abuse disorder, HIV diagnosis/treatment records, release of information on minors – note this is not an exhaustive list) statutes and regulations. Organizations can also provide additional protection for specific types of information that are deemed sensitive. The following guidelines apply unless otherwise dictated by statute or regulation:

1. Where permitted by law and in accordance with legal requirements, systems SHALL always support release of additionally protected information. ^§sec-17

2. Implementations SHALL ensure that release of the information without explicit request of the patient/member is based on organization policy consistent with Federal and State regulations. ^§sec-18 Examples are legal requests for information and "break glass" to treat a patient that is unable to provide consent.

Security Contexts for Da Vinci IGs

Da Vinci IGs span several security contexts related to the exchange of information between requester and supplier of data. These security contexts include:

Exchange without PHI

1. Access to openly available data (e.g. Payer's provider directory)
   1. No identity, access, authentication, or audit requirements
   2. Access restrictions are only imposed to protect the site or manage the ability of the site to handle valid requests (e.g. protection against Denial of Service attacks)
2. Access to Sensitive Business Information (e.g. open schedule slots for a provider, blinded and aggregated patient data)
   1. Identity, access, authentication, and/or audit requirements are up to the Information Supplier
   2. Requirements should be consistent with current best practice for such information (if access includes exchange of PHI see the following section)
3. Exchange of a token or internal key
   1. Secure exchange between trusted entities
   2. Access rights are inherent in the token
   3. Internal key does not necessarily imply access rights
   4. Requirements should be consistent with current best practice for such information (if access includes exchange of any unencrypted PHI see the following section)

Exchange of PHI for Treatment, Payment, Operations (TPO) (as defined by HIPAA)

This includes exchange of PHI between:

• two covered entities,
• a covered entity with a third party (e.g. for quality reporting), or
• a covered entity and the member/patient.

In all cases, (in accordance with HIPAA security and privacy rules):

1. Information Source systems SHALL log all IDs, access rights, requests, and exchanges. ^§sec-19

2. Information Source systems SHALL verify rights of the requestor to have access to the member's/patient's record. ^§sec-20

Requesting Information	Information Supplier	Covered by HIPAA under (see regulations for details)	Automated Declaration of Purpose of Use on Request
Patient/Member	Covered Entity	Right of Access	N/A
Provider	Provider	TPO	(need process)
Provider	Payer	TPO	(need process)
Payer	Payer/Provider	PO including Coordination of Care	(need process)
Other (e.g. CMS)	Provider/Payer	PO (member authorization where required)	(need process)

Note: (need process) – there is no current mechanism (outside of CommunicationRequest) to declare a purpose of use when accessing data using RESTful mechanisms (e.g. GET) – the standards for the need to be addressed within HL7.

Exchange via Business Associates (BA) – for a Covered Entity

1. Both Covered Entity and BA are defined and scoped by HIPAA
2. Requires a HIPAA compliant Business Associate Agreement (BAA)
3. BA inherits all the requirements and responsibilities of the covered entity that are not reserved by the covered entity (e.g. disclosure reporting)