Implementing the Attestation Requirements in the New HIPAA Rule

Thursday. June 06, 2024 - 9 mins

The new HIPAA Privacy Rule to Support Reproductive Health Care Privacy intends to strengthen the protections in the HIPAA Privacy Rule to prohibit disclosure of protected health information for the purpose of conducting legal prosecution against lawful reproductive healthcare. The goal is to prevent access to information about lawfully-received reproductive healthcare for the purposes of investigating to impose penalties, or identifying individuals involved in the process of care including the patient and providers for that purpose. This rule is going into effect on June 25, 2024 with a 180-day window for compliance.

One of the major components of this new rule is the requirement for the covered entity to obtain an attestation from the requester in which the requester affirms that the requested data will not be used for the purposes prohibited by the rule. The rule does not require the covered entity to do further investigation to ensure the veracity and sincerity of the attestation, and allows the covered entity to simply trust the attestation, unless it has reasons to believe otherwise. There is a requirement to cease any disclosure should it become clear that the attestation was false or erroneous.

The attestation should also include language that shows the requester confirms their awareness of the potential criminal liabilities for breaching the rule.

The rule allows the attestation to be in electronic form and electronically signed by the person requesting the disclosure but it does not mandate any specific format or standard.

It also stipulates that each attestation is limited to the specific instance of disclosure and each new disclosure request will require a new attestation. This rules out the idea of having a blanket attestation as part of the overarching trust agreement that would cover many disclosures over time.

Based on this summary I share some thoughts on the implementation of this part of the rule.

Workflow

The most important (and tricky) component of the implementation is the workflow for requiring the attestation.

Upon receiving a request, the covered entity can inspect the requested data to see if there is any reproductive health data (using a security labeling service) and then ask for an attestation only if such data is requested. This is problematic because it leaks the existence of reproductive data and effectively creates a mechanism for a requester to learn (by inference) whether such data exists about a patient by observing whether it is asked to provide an attestation. This is contrary to the spirit of the rule but perhaps also to its letter since the rule prohibits sharing any information that could lead to identifying anyone involved in reproductive health care which implies protection against sharing information that could lead to such conclusion by inference.

An alternative is to require the attestation to be present for every request. This will ensure that if there is any reproductive health care data in the response, the requirement for the attestation is met. But consider the case in which a request without an attestation is received. If the requested data does not indeed contain any reproductive health care data and this request is decline (merely because the attestation is not present), then the covered entity has declined a request for disclosure without a valid reason which could be a violation of information blocking rules.

To balance these two competing requirements, the covered entity can implement the following workflow upon receiving a request:

• If the request includes an attestation, proceed to next steps for sharing all the information (i.e., verify if sharing is authorized by other policies, such as consent where it is applicable),

• If the request does not include an attestation, identify all reproductive healthcare information subject to the rule (using a security labeling service), and redact them from the outgoing response.

With this workflow, the requirement for an attestation would not act as a signal confirming the existence of reproductive health care information but also valid requests without an attestation would not be declined.

Data Subject to The Rule

The rule deliberately establishes a broad definition of reproductive health care data. This is more expansive than the data subject to other similar legislations (e.g., Maryland House Bill 812 (2023)) that more specifically target abortion care.

This makes the implementation of sensitivity labeling more complex and nuanced since these categories of sensitive information need to be distinguished and a different sensitivity label should be used to tag each category.

The current sensitivity value set defined in the HL7 terminology does not include codes with sufficient granularity to distinguish these categories and therefore, custom labels have to be used to accomplish this.

We need an initiative to regularly update this value set in alignment with emerging jurisdictional policies and provide guidance on which sensitivity code to use for each category of sensitive data in the FHIR Data Segmentation for Privacy.

Delivery

To present the attestation to the covered entity, the requester can include a reference to it in the request as part of the authorization token. Depending on the type of the token this may be a custom attribute assertion in a SAML token (based on a profile such as IHE XUA) or a custom claim in a JWT token (based on a profile such as the IHE IUA).

Interoperable implementation requires an agreement on a standard name for this attribute to be used consistently across implementations. I think for clarity, it is helpful if the attribute name would include the name of the regulation directly (e.g., hipaa_rule_2024_attestation).

The value of this attribute should be a link to the actual attestation document where the covered entity can retrieve it. The requester can push the document into the covered entity’s server in advance, or host the document and allow the covered entity to access it (this requires the covered entity to have the credentials to access this document). It is also possible to include the document in the request itself as part of a bundle if the protocol in use allows it.

An appropriate trust agreement between the requester and covered entity may enable the covered entity to trust the claim included in the request and allow the process of retrieving the attestation document to take place asynchronously after the request is fulfilled to improve the response time. Note that this is only possible because the attestation is an opaque document and there are no choices (like options to opt out from) in it, otherwise, the covered entity would have to inspect the attestation before determining how to respond. This raises the question how much the covered entity is responsible in validating the attestation (see the note on freshness below).

Signature

The rule permits the use of electronic signature. This does not need to be a cryptographic digital signature, although with the appropriate infrastructure in place, cryptographic signatures can also be used. Even though the rule does not require the covered entity to verify the veracity of the attestation, arguably the validity of a digital signature still has to be determined to ensure that the attestation actually originates from the requester.

It seems to me that the rule requires the attestation to be signed by the human user initiating the request rather than the requesting organization, but that is ultimately a legal question. If an organization can (as the user) sign the attestation, it is also possible to argue that the signature on the authorization token (that includes the attestation claim) may suffice since the token is often signed by the organization or a trusted third-party vouching for the claims.

Attestation Format

The rule requires the attestation to be in plain language (and at another point it mentions that it could be in the form of accepting a number of checkboxes), but it does not prescribe any specific format. There are benefits in using a standard structured document such as a FHIR resource to record the attestation since this provides an interoperable way to convey and interpret the document and its metadata. Note that to use a FHIR resource for this purpose, the ecosystem itself does not have to be a FHIR-based exchange ecosystem; regardless of the format of the actual health data and the protocols used by the covered entity, the attestation can be shared as a FHIR resource.

The most suitable resource to carry this is a FHIR Contract resource which allows individual terms of the attestation to be stored granularly. If an end user actually submits a form for the attestation, the original form can be captured as a FHIR QuestionnaireResponse. A Contract resource can be derived from the QuestionnaireResponse based on the associations defined in the Contract resource specifications or via the more general and flexible $extract operation defined by the Structured Data Capture (SDC) Implementation Guide.

Since the attestation seems to be an opaque form (without a choice to opt in and out from some of the terms) I cannot think of any specific benefits for recording it in the more granular and computable format of Contract resource at the moment, but it may make the implementation easier in future if more complexity is added to the attestation or if more verification is required from the covered entity.

Freshness

The rule requires that a new attestation should be submitted for every request –therefore ruling out using a blanket attestation that applies to many requests. However, since the attestation is generic and does not differ in content from one request to another, it is easy to replay an old attestation for a new request. This raises the question whether the implementation should include technical mechanisms to ensure the freshness of the attestation. For example, a unique transaction identifier can be required to be included in the attestation before signing. The covered entity can then validate the freshness of the attestation by matching the request ID with the identifier included in the attestation.

Again, it is not clear to what extent the covered entity is expected to verify the attestation (including the requirement for freshness) and to what extent it can rely on the requester. If the covered entity can trust the requester that the attestation was obtained freshly for the request in question, this technical mechanism would be unnecessary.

Tweet