POCP Prescription Enrollment
0.1.0 - CI Build US

POCP Prescription Enrollment - Local Development build (v0.1.0). See the Directory of published versions

Consents and Authorizations

Patients must authorize certain activities associated with fulfilling a specialty product, including the sharing of clinical information, obtaining insurance company approval, identifying other financial assistance and providing other patient support services.

In addition, healthcare providers may also need to provide their authorization for certain data sharing or activities performed on their behalf by a patient support program or others involved in getting the prescription to the patient.

This section describes how the enrollment application obtains those authorizations and transmits them to partner systems.


  • This section uses the word, “authorization”, to represent the range of consents and authorizations provided by both patients and healthcare providers.
  • An authorized person may provide authorizations on behalf of the patient. While the data representation of an authorized party is called out below, the material in this section generally intends to refer to both the patient and authorized party when using the word, “patient”.

Process Overview

Process Characteristics

The enrollment application obtains and transmits authorizations in a way that provides:

  • authentication - validation that the patient or provider is who they say they are at the time authorization is given. The app uses methods appropriate to the patient and provider workflows to confirm a user’s identity:
    • patients receive a patient-specific link at the patient portal account, email or SMS specified by their provider. The content of the link is verified when the patient navigates to the application
    • providers are authenticated by the EHR, and their identity is passed to the application when it is opened using the SMART App Launch protocol
  • integrity – proof that the authorization has not been altered during transmission or at a later point, through use of a digital signature
  • non-repudiation - evidence to prevent the patient or provider from denying they gave the authorization, through an auditable record of the identity verification and event details.

Generalized Process Steps

Capturing the authorization

  • Prior to obtaining a user’s authorization, the application verifies the user’s identity.
  • The application presents the authorizations and the user indicates their choices (e.g., a patient indicates Yes to receiving text messages, No to receiving phone messages).
  • The user types their name to indicate that they understand and commit to their choices (representing their authorization signature).
  • The application records the authorization details in its audit trail, including identifying information about the patient and event specifics including a date/time stamp, identifying user system details such as IP address, patient or provider identifier, etc.
  • The application also captures this authorization data in a FHIR QuestionnaireResponse for transmission within a FHIR Consent resource.
  • The application generates a digital signature (JSON Web Signature / JWS) based on the authorization data using its private key and records it in a FHIR Provenance resource that references back to the Consent resource holding the authorization details.

Transmitting the authorization and signature

  • Both the Consent resource (carrying authorization details) and Provenance (holding the digital signature) are transmitted to the partner system.

Verifying that the authorization data hasn’t been modified

  • The verifying system retrieves the application’s public key to use in verifying the signature transmitted with the authorization data.
    • The application publicly posts its public key on a website as a JSON Web Key Set (JWKS) at a .well-known address on the server.
  • The recipient verifies the signature value against the authorization data using the public key and signature algorithm indicated by the JWS.

Transmission Detail

Authorization information

Authorizations are transmitted using FHIR Consent resources, whether given by the patient or a healthcare provider. Key information is represented in the following elements:

  • Consent.status reflects the status of the authorization
    • The value active indicates a completed authorization.
  • Consent.patient identifies the patient to which the authorization is related
  • Consent.dateTime indicates when the transmitted Consent resource was generated
  • Consent.performer references the party who provided the authorization (the patient, authorized representative or provider)
  • Consent.organization references the provider organization at which the prescription originated
  • Consent.sourceAttachmentcontains a QuestionnaireResponse holding the specific authorizations provided by the patient or provider.
    • The attachment contains the following information
      • specific individual authorizations granted by the patient or provider
      • items presented to the patient or provider for which they withheld authorization e.g., recording that the patient did not agree to receive voice messages at a given phone number
      • patient name and demographic information
      • date/time authorizations were completed
  • Consent.sourceAttachment.data= Base64-encoded authorization QuestionnaireResponse
  • Consent.sourceAttachment.creation indicates when authorization was documented


  • The sourceAttachment contains the authorization details as well as context information so that it may serve as a complete and human-readable record of the authorizations and the authorizing event. This approach enables the authorization to be verified independently of the FHIR Consent in which it was transmitted. This:
    • protects this authorization record from subsequent changes to patient or other data in the receiving system
    • prevents problems caused by typical data management processes that may modify URL references (e.g., to the patient or custodian organization) in the Consent resource–making related information unreachable.
  • The .scope and category elements are required to be populated in the FHIR Consent resource and will contain values in transmissions from the enrollment application. However, because these elements are undergoing re-definition for upcoming FHIR versions, receiving systems should rely instead on the authorization details attached in the Consent.sourceAttachment element.

Digital signature

The digital signature covering the authorization information (step 6 in the process flow above) is based on the document transmitted in the Consent.sourceAttachment.data element–reflecting the authorizations provided by the patient, authorized representative or provider.

The signature itself is a Base 64-encoded JSON Web Signature (JWS) that conforms with the JSON Signature rules in the FHIR specification for use of a JWS-Signature RFC 7515: JSON Web Signature (JWS).

  • The signature is a detached signature, which means that the content that is signed is not included in the signature itself. Instead, the JWS is created using a representation of the content as the payload but the payload representation is deleted from the JWS before transmission. Specifically, the deletion is accomplished by replacing the second field of the JWS Compact Serialization (which contains BASE64URL(JWS Payload)) value with an empty string
    • To use the modified object, the recipient reconstructs the JWS by re-inserting the payload representation and using the resulting JWS in the usual manner.
  • The signature contains a “CommitmentTypeIndication” element for the Purpose(s) of Signature equal to “1.2.840.10065.”, Consent Signature. This value is also reflected in the Provenance.signature.type element.

The signature is transmitted using a FHIR Provenance resource. Important information is represented in the following elements:

  • Provenance.target references the associated Consent resource
  • Provenance.agent references the person who gave the signature
  • Provenance.signature holds the electronic signature
  • Provenance.signature.type = “1.2.840.10065.”, Consent Signature
  • Provenance.signature.when reflects the date/time when the signature was generated
  • Provenance.signature.who references the party giving the authorization (the patient, authorized representative or provider)
  • Provenance.signature.onBehalfOf references the patient, if the signer (Provenance.signature.who) is an authorized representative
  • Provenance.signature.sigFormat = “application/jose”
  • Provenance.signature.data is the Base 64-encoded JWS

The enrollment app signs the Consent.sourceAttachment.data element’s content with its signing key (RSA private key).

The signing method is ES256 using…

Verification process

To use the detached signature conveyed in the Provenance resource, the recipient…

  • reads the signature algorithm from the JWS protected header. In this case, ECDSA
  • retrieves the authorization document conveyed in the Consent resource referenced in the Provenance.target element. (This is the document conveyed in the referenced Consent’s Consent.sourceAttachment.data element)
  • reconstructs the full JWS (including payload) by re-inserting the authorization document into the detached signature
  • splits the JWS Compact Serialization into two parts, the JWS Signing Input (Header.Payload) and the JWS Signature
  • retrieves the enrollment application’s RSA public key (see Obtaining the public key, below)
  • verifies the signature value against the signing input using the RSA public key and signature algorithm.

Obtaining the public key

Note: This guide adapts certain conventions established in the Protocol Details section of the SMART Health Cards Framework to support industry consistency in the verification of document signatures. These conventions follow.

The enrollment app publishes the corresponding public key (public key) at /.well-known/jwks.json. The recipient uses that public key to verify the signature conveyed in the Provenance.signature element.

Format of the enrollment application’s public key

  • The public key used to verify signatures is represented as a JSON Web Key (see RFC7517), with some of its properties encoded using base64url (see section 5 of RFC4648):
    • "kty": "EC", "use": "sig", and "alg": "ES256"
    • “kid” equal to the base64url-encoded SHA-256 JWK Thumbprint of the key (see RFC7638)
    • "crv": "P-256, and "x", "y" equal to the base64url-encoded values for the public Elliptic Curve point coordinates (see RFC7518)
    • the Elliptic Curve private key parameter "d" is not populated

Publishing of the enrollment application’s public key

The enrollment application’s public key is published as a JSON Web Key Set (see RFC7517) as follows:

  • The public key is made available at «iss value from JWS» + /.well-known/jwks.json
    • with [Cross-Origin Resource Sharing (CORS) enabled](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin
    • using TLS version 1.2 following the IETF BCP 195 recommendations or TLS version 1.3 (with any configuration).
  • The URL at <iss value from JWS> uses the https scheme and does not include a trailing /.

  • The signing key in the .keys[] array can be identified by kid following the requirements above (i.e., by filtering on kty, use, and alg).