What is digital consent?
A Digital FHIRBlocks Consent is a type of a Verifiable Credential as defined by the Decentralized Identity working group at the W3C. It is common to represent these Consents as a JSON Web Object, and is digitally signed by the Consent Issuer, which is commonly a patient, in the case of healthcare Consents. A Digital Consent contains various “claims” (in W3C parlance), which in fact describe the scope, business purpose, duration, and other parameters. These claims are managed using the JSON-LD standard, and are usually defined as part of the client onboarding process for FHIRBlocks. FHIRBlocks provides a set of pre-built JSON-LD structures to aid this process, which collectively form an open, extensible “grammar” for defining, granting, and managing Consents.
Note that with FHIRBlocks e-forms, Consent credentials can drive the creation of patient-augmented auto-filled PDF forms, which are digitally signed by the Consent issuer (e.g., Patient). These filled PDF acroforms provide seamless integration into current business processes and health information management systems, thus providing strong support for legacy systems.
Where are granted consents stored?
The FHIRBlocks platform stores completed Consents in Consent Wallets, which are available within “Identity Hubs” in the Azure cloud offering (known in FHIRBlocks as “Consent Pools”) and/or on Consent Wallets on mobile devices (iOS, Droid). The specifics of individual use cases typically determine the most appropriate storage location, and the various methods can be combined. Additionally, granted Consents can also be stored within legacy EHR systems.
Can consents be revoked?
Yes. Digital Consents can be revoked. FHIRBlocks provides a Revocation Ledger whereby an issuer can rescind a previously issued Consent. Various “Relying Parties” in possession of a Consent (e.g., a healthcare provider validating a digital power of attorney) can query the Revocation Ledger to determine whether the Consent had been subsequently revoked.
Once a consent is given, what then enforces that consent?
A range of enforcement capabilities are supported. Consents rendered as digitally signed PDFs can be incorporated into legacy workflow systems, for example, a Health Information Management department Release of Information Workflow. Digital Consents stored in Consent Pools (see above) can be used to power Policy Enforcement Points (PEP): PEPs can use Consents to determine whether a proposed data use action is allowed under applicable Consent policy. PEPs can augment OAUTH2 compliant authorization servers, bringing the power of digital Consent to a wide array of OAuth2 protected resources (e.g., a FHIR resource server) as well as Extract-Transform-Load (ETL) platforms commonly used in construction of data lakes.
How does the Data Owner determine their consent attributes?
Data Owners are typically individual patients. FHIRBlocks provides a prebuilt set of Consent templates, that can be created as needed using the FHIRBlocks admin interface. Data Owners use these templates, and populate them with their consent choices (example: selection of a Consent expiration date). Once all choices are made and validated by the Data Owner, the Consent is digitally signed by the Data Owner, and placed into the Consent repository as defined in the template.
Additionally, FHIRBlocks is building consent templates based upon the USCDI spec (1.0, 2.0…) so that a healthcare consumer, such as a Patient may choose their data access and sharing preferences in a fine-grained manner.
How are Data Owner consent decisions exposed?
Exposure of Consent decisions is use case dependent. As an example, a couple may elect to provide one another a medical power of attorney (POA), but keep those Consents private, storing them on each other’s mobile device. Only when the POA is needed to make some care decision would it be disclosed to a health provider. In other cases, the Consent can be provided back to the requesting organization’s Consent Pool, where it would be securely stored and used to adjudicate use of information pursuant to the policy described in the Consent.
Users can interact with consents via a mobile app, electronic forms, and HTML.
How does a Requesting Party determine their involvement in certain consents?
In the FHIRBlocks architecture, and linking back to other standards bodies; i.e., W3C, DIF, OAuth2, OpenDID, OpenID Connect, and Self-Issued OpenID Connect Provider DID profile (SIOP), there are two classes of Relying Parties (RPs): Health Information Consuming RPs (HICRP) and Consent Consuming RPs (CCRP)
HICRPs will make a request to a Data Controller for access to health information, and may provide Consent Verifiable Credentials (CVCs) which are then evaluated to determine whether access should be provided.
CCRPs receive CVCs and use those credentials to adjudicate requested access to information, as well as to maintain an immutable record of consent decisions issued by data owners.
Can digital consents be Stored as FHIR Consent Resources?
Are consents stored on a Blockchain?
No. Healthcare Consents are a form of personal health information, and protected by regulation. Conversely, blockchain technology is intended to create a shared source of truth across parties. Thus, it is inappropriate to store Consents on the blockchain.
Does FHIRBlocks use a Blockchain? If so, how?
Yes. More specifically, FHIRBlocks GEN4, like its predecessors, is based on Linux Foundation’s Hyperledger Fabric. Fabric holds a “DID Document” describing each decentralized identity, the credential revocation ledger, and the audit ledger and other schema.
A DID Document describes a portion of an identities’ decentralized identity. In this context, an entity includes patients, provider organizations, clinicians, or any other entity as defined by use cases – including devices. The DID Document contains the entities’ public keys, a delineation of publicly known “services”, and other claims that an entity may choose (but not required) to disclose. It is important to note that any entity may read the contents of any entity's DID document, in alignment with the work of the W3C.
Can FHIRBlocks provide identity management for remote monitoring and IOT device management?
Yes. Any smart device capable of creating public key pairs and basic network connectivity can create its own identity, and thus participate in the FHIRBlocks Consent ecosystem. As an example, the Raptor Engine (a FHIRBlocks software framework for Apple iOS) can be deployed on Apple iWatch products, thus allowing the watch to have its own digital identity. With identity in hand, a patient (or whomever) can then authorize the device to access health data. Moreover, various health providers can use this identity to ensure provenance and trust on the device (i.e., has the device been properly calibrated and tested?), allowing it to contribute health data to a patient record.
Can FHIRBlocks allow opt-in for patients, allowing them to contribute (and control) their data and receive recommendations/advice?
Yes. Patients and other health data owners have the ability to opt-in and contribute data for various studies, clinical trials, or many other data sharing use cases by providing Consented access. Whether and how these patients then receive recommendations and advice is a subject for the applications provided by a provider, payer, pharma or life-science organization, etc.
Can FHIRBlocks help providers assess where new standards of care and/or treatment plans can be proposed to patients?
FHIRBlocks allows providers to quickly introduce new types of Consents, thus enabling the collection of new data sets to drive new care standards and treatment plans, and ultimately to improve patient engagement and smooth digital health delivery.
How can one take existing PDF/paper consent forms and move them into the FHIRBlocks digital consent platform?
The first step in this process (if not already performed) is to convert the PDF into an Acroform, which is Adobe’s fillable PDF standard. With this accomplished, the wizard design tool is used to define a strategy and UI flow for data collection, which may be based on using existing Verifiable Credentials, or soliciting the user directly using our turbo-tax like data collection interface. Using the FHIRBlocks platform, all of this design work results in the creation of a formal specification of the Consent, and how required data may be collected. The formal specification is represented in FHIRBlocks’ grammar for expressing Consents. The new Consent type is then published and made available for use by users accessing our platform over the web or with mobile devices.
Does FHIRBlocks tie consents to a specific use case of health data?
Strictly speaking, the creation of a Consent template is controlled by the party responsible for defining and implementing Consent policy. While in theory it’s possible to create a Consent template that calls for unlimited use of data, it’s more common, in our experience, that the Consent would contain language that set forth the specific intended use and limitations of data use. The ability of the FHIRBlocks platform to define these scope and limitations is inherent in the platform.
How does FHIRBlocks support analytics of consent types, to assess whether new use cases are covered with existing consents, or new consents may be required?
FHIRBlocks maintains versioned access of various Consent templates. This capability allows compliance offers, as an example, to review templates and provide the required assessment. In cases where current templates do not provide adequate coverage for a new contemplated use case, a new derivative template can be created and put into service.
Does FHIRBlocks support existing workflow systems?
Yes. FHIRBlocks grammar for expressing Consents includes specification of key trigger events (a Consent enforcement event, a Consent revocation event, etc). These events can then create “triggers” in current generation workflow platforms, including Microsoft Dynamics.
Does FHIRBlocks support writability into FHIR based EHRs, to create Consent and Provenance resources?
Yes. FHIRBlocks provides integration into FHIR servers such that a reference to a digital Consent can be made within the FHIR repository using Consent and Provenance resources.
How does FHIRBlocks support anonymization of patient data?
In certain use cases, a patient may elect to contribute their health data to some project that seeks to improve care by analysis of “anonymized” data (patient identifying information such as name, address has been redacted). In these cases, FHIRBlocks manages the creation of the Consent template, the collection of patient Consent, and the lifecycle management of granted Consents. In cases where a patient withdraws Consent (if allowed), then FHIRBlocks provides an “event” to the analytics application, allowing patient data to be removed from consideration.
Does FHIRBlocks support the provenance of medical devices?
Yes. Medical devices can maintain their own unique digital identity. Consequently, various certification processes can be created and managed that require devices to be calibrated/assigned, and then provenance can be established and tracked through the devices’ lifecycle.
Does FHIRBlocks support authorized third parties to access health data?
Yes. A third party can create their own digital identity. With that identity in hand, a data owner can then provide that third party Consented access as otherwise described herein. When needed, that third party can then request access to the data, and provide the signed digital Consent to the resource server. The resource server validates the authenticity of the request, and fulfills the request as determined by the policy inherent in the Consent.
Where is the digital identity stored?
We support W3C standards for decentralized identity (DID-core). In the DID-core architecture, the private keys associated with an identity remain within the Wallet. The public keys, together with any defined services and methods (as those terms are used in DID-core) are stored in the FHIRBlocks DID method, which is based on blockchain technology. Under no circumstance is Protected Health Information stored on the blockchain distributed ledger.
Does FHIRBlocks provide “security tokens”?
FHIRBlocks manages Consents by creating sets of Consent Verifiable Credentials (CVC), which are a special type of Verifiable Credential, defined by the W3C and DIF. A CVC can be thought of as a type of security token. It contains claims that describe the type (level) of Consent granted. Refer to (https://app.swaggerhub.com/apis/fhirBlocks/FHIRBlocksG4-BlueBerry/2.0.1) for a complete description of CVC claims. In general terms, CVCs follow data exchange guidelines established by ONC and supported by FHIR/HL7, specifically USCDI V1.
Does FHIRBlocks support SAML?
No. FHIRBlocks does not support the legacy standard SAML. However, enterprise-specific custom arrangements can be configured.
Is a Hyperledger Blockchain necessary?
The FHIRBlocks DID method is based on Hyperledger, the predominant enterprise blockchain technology in industry. Additionally, Hyperledger is used to support credential revocation and audit services. A Universal Resolver function is in the FHIRBlocks roadmap, which will enable the use of any DID method that is part of the W3C community. That said, FHIRBlocks abstracts the distributed (blockchain) ledger technology (DLT) layer; thus, as alternative DLT methods mature within the Hyperledger community (e.g., Areis and Indy) and others (ION/Sidetree) emerge with more desirable features, FHIRBlocks can easily evolve with them.
Does FHIRBlocks have standard APIs and the technology i.e. REST, API management?
API’s are available at https://app.swaggerhub.com/apis/fhirBlocks/FHIRBlocksG4-BlueBerry/2.0.1