PDF icon PDF herunterladen
Appl Clin Inform 2024; 15(02): 342-356
DOI: 10.1055/a-2291-1482
Research Article

Pediatric Consent on FHIR

Anton Voronov
1   College of Health Solutions, Arizona State University, Phoenix, Arizona, United States
,
Mohammad Jafari
1   College of Health Solutions, Arizona State University, Phoenix, Arizona, United States
,
Lin Zhao
2   HonorHealth, Phoenix, Arizona, United States
,
Melissa Soliz
3   Coppersmith Brockelman PLC, Phoenix, Arizona, United States
,
Qixuan Hong
4   Ira A Fulton School of Engineering, Arizona State University, Phoenix, Arizona, United States
,
John Pope
2   HonorHealth, Phoenix, Arizona, United States
,
Darwyn Chern
5   Copa Health, Phoenix, Arizona, United States
,
Megan Lipman
6   Jewish Family and Children's Services, Phoenix, Arizona, United States
,
Adela Grando
1   College of Health Solutions, Arizona State University, Phoenix, Arizona, United States
› Institutsangaben

Funding This research was funded by the National Institute on Drug Abuse, through the Substance Use HeAlth REcords Sharing (SHARES) grant (9R01DA056984-06A1).
› Weitere Informationen
Auch verfügbar aufeRef
 
 als PDF herunterladen Lizenzen und Reprints

Abstract

Background Standardizing and formalizing consent processes and forms can prevent ambiguities, convey a more precise meaning, and support machine interpretation of consent terms.

Objectives Our goal was to introduce a systematic approach to standardizing and digitizing pediatric consent forms, which are complex due to legal requirements for child and legal guardian involvement.

Methods First, we reviewed the consent requirements from the Arizona regulation, and we used 21 pediatric treatment consents from five Arizona health care organizations to propose and evaluate an implementation-agnostic Consent for Treatment Framework. Second, we assessed the adequacy of the Fast Healthcare Interoperability Resources (FHIR) to support the proposed framework.

Results The resulting Consent for Treatment Framework supports compliance with the state consent requirements and has been validated with pediatric consent forms. We also demonstrated that the FHIR standard has the required expressiveness to compute the framework's specifications and express the 21 consent forms.

Conclusion Health care organizations can apply the shared open-source code and FHIR implementation guidelines to standardize the design of machine-interpretable pediatric treatment consent forms. The resulting FHIR-based executable models may support compliance with the law and support interoperability and data sharing.


 

Keywords

privacy - HL7 - FHIR - pediatrics - consent

Background and Significance

Informed consent is a shared medical decision-making process between patients and health care providers. It aims to protect vulnerable patients and honor their autonomy by law and medical ethics.[1] Treatment consents cover various medical decisions—pursue diagnostic results, prevent disease, reduce pain, and prolong life.

Many challenges, such as poor literacy, can impact a patient's understanding of treatment consent.[2] Engaging the patient to ensure their understanding is essential in pediatric consent, where the consent process may require parental permission and, depending on the situation, childhood assent.[3] In some cases, the requirement of childhood assent makes it clear that there need to be further medical explanations that facilitate proper understanding and document the minor's preference in medical decision-making.[4] [5] Adolescents' consent may also be subject to other privacy protections.[6] [7] [8]

Standardization and formalization of consent processes and forms can avoid ambiguities and convey more precise meaning through digital tools, such as multimedia. A major obstacle to medical consent is its unstructured nature and how most hospitals rely on paper-based forms.[9] Creating machine-interpretable consents can further facilitate the consent process, for example, by enabling automatic state and federal policy and law compliance checking. Automated legal compliance is especially relevant in the case of pediatric treatment consent, where a state may impose restrictions on the validity of the consent based on treatment type (e.g., abortion) and minor age.[6] [7]

Various formalisms have been used to model computer-interpretable consents. Grando et al used ontologies to model research consent directives.[10] Their ontology inspired the Research Permissions Management System built and tested by the University of South Carolina.[11] Grando et al's ontology was also incorporated into an eXtensible Access Control Markup Language engine and used to maximize the reuse of biosamples for research compliance with patient permissions.[12]

More recently, Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR) were used to model medical treatment consent directives.[13] Based on stakeholder dialogue, Bialke et al and Lin et al identified ethical, legal, and administrative reasons why patients must give explicit consent to medical treatment.[14] [15] Both studies identified major required consent components—such as treatment information, consent, and signature and mapped them into the FHIR Consent Resource to demonstrate its suitability to support the exchange of electronic consent.

The FHIR Consent Resource provides a powerful mechanism to record consents in a structured and computable form. Capturing and recording consent in electronic form with appropriate metadata enables the integration of consent documents into the electronic health record system and ensures that consent can be searched and retrieved. Capturing consent in a standard and interoperable format enables different systems to understand the consent and its contents consistently. Recording consent rules in a machine-readable form (i.e., using computable consents) enables the application and enforcement of Clinical Decision Support (CDS) systems to assist the patients in their decision to consent to a treatment procedure.

Our study takes a systematic approach to assess the suitability of the FHIR Consent Resources to digitize and standardize pediatric treatment consents. This study proposes a Consent for Treatment Framework to support compliance with consent requirements from Arizona regulations,[16] validates the framework with pediatric treatment consents from five health care organizations, and assesses the adequacy of the FHIR Consent Resources to support the proposed Consent for Treatment Framework.


 

Materials and Methods

Consent Forms

Twenty-one pediatric consent treatment forms were collected from five pediatric health care urban organizations in Arizona. Information that could be used to identify the health care organization/s was removed ([Supplementary Material], available in the online version)


 

Methodology

Our approach consisted of ([Fig. 1]):

  • Proposing a Consent for Treatment Framework that supports compliance with state requirements and validating it with consent for treatment forms from pediatric health care organizations.

  • Assessing the expressivity of FHIR Consent Resources (FHIR r5.0.0) to support the proposed Consent for Treatment Framework.

Zoom
Fig. 1 The methodological approach consisted of proposing and validating pediatric consent forms, a Consent for Treatment Framework, and mapping it into FHIR consent resources. FHIR, Fast Healthcare Interoperability Resources.

Consent for Treatment Framework

First, two researchers and a lawyer identified the attributes required to support compliance with certain state legal consent requirements.

Second, two researchers iteratively and independently reviewed the consent forms to identify additional relevant pediatric treatment consent attributes not required by state law but present in the forms. The goal was to reuse/adapt attributes proposed in the literature and, only when needed, introduce new attributes. Disagreements between researchers were resolved by a physician.

Two coauthors shared 12 pediatric consent forms used at their organizations. The other nine consents were publicly available and selected to increase diversity. After selecting and reviewing 21 consent forms, saturation was achieved. No more new attributes were introduced, and no more changes in the existing attributes were needed. As in Umberfield et al, we annotated the consent forms.[17] As in the Lehmann et al study, we aimed to propose the minimum set of attributes to support pediatric treatment consent.[9]

Finally, we reviewed the literature by searching PubMed for published papers published between 2012 and 2023 containing the words (“FHIR” OR “HL7” OR “Ontology” OR Ontological) AND (“permissions” OR “consent”) in the title and abstract.[18] We also used snowballing to identify additional papers. Papers that presented theoretical formalisms or executable models to model consent forms in general, not only pediatric consents, were retrieved.


 

Mapping of FHIR Consent Resources into the Consent for Treatment Framework

[Fig. 2] depicts our architecture for digitizing treatment consents into computable FHIR consent resources.

Zoom
Fig. 2 Modeling consents using FHIR resources; adoption of the Consent for Treatment Framework and interplay of FHIR consent artifacts—Questionnaire, QuestionnaireResponse, Consent Profile, and Consent. Dark boxes represent FHIR artifacts; gray boxes refer to other artifacts not modeled directly as FHIR resources. FHIR, Fast Healthcare Interoperability Resources.

Below, we describe the mapping process:

  • Consent Forms are the original material presented to patients to inform them and collect their approval for various procedures and treatments. These forms are usually available in paper forms.

  • Manual modeling is the process where each form portion is mapped into a question in the FHIR Questionnaire resource. Manual mapping of a form into an FHIR Questionnaire is a process where the form narrative and inputs are modeled as questions. Depending on the input type (e.g., text, code, reference, etc.), a “type” for the answer to the question is selected. There are a wide variety of capabilities (both in the Questionnaire resource itself and the related implementation guides such as Structured Data Capture [SDC] Implementation Guide[19]) for advanced management of the input that goes far beyond a digital simulation of a paper form; for example, logic to conditionally enable questions, read-only or prepopulated answers, and automatically computed answers. This stage is also an opportunity to reengineer and redesign the consent forms to fit them better for the digital user experience, for example, by linking additional explanations to each question.

  • Questionnaire [20] and QuestionnaireResponse [21] are part of the FHIR core specifications and support the representation of forms (in general) and structured capturing of general forms where a user is guided through several questions to enter and submit information. The QuestionnaireResponse resource provides a vehicle for capturing the corresponding responses to the questions in a Questionnaire resource. This pair of resources provides a way for capturing the grantor's answers to the form questions in a way closest to the experience of filling out a paper form. While many of the responses provided to the consent form are ultimately incorporated into an FHIR Consent Resource, any portions of the consent form that are not consequential from a computational perspective are not incorporated into the Consent resource and must be retained in the QuestionnaireResponse resource—i.e., without being mapped to an attribute in the deriving Consent resource. Lackerbauer et al used a similar method for modeling consent.[22]

  • Mapping rules are recorded in the Questionnaire resource and enable an automated mapping engine to extract a Consent resource based on the responses provided in a corresponding QuestionnaireResponse resource.

  • The automatic mapping of QuestionnaireResponse elements into other FHIR resources, including the Consent resource, is guided by the $extract operation defined by the SDC Implementation Guide.[19]

  • The Conceptual Framework developed by this research provides the basis for the mapping rules that determine how responses to a consent form correspond to the attributes in a Consent resource.

  • The resulting Consent resource instance traces back to the QuestionnnaireResponse resource it derived from. For business and legal purposes, it is important to reproduce the evidence behind the data and rules captured by the Consent resource.

  • FHIR profiles define restrictions and constraints on the attributes and values of a resource to fit a specific use case. Based on the conceptual framework, we defined a “Treatment Consent Profile” for the FHIR Consent resource. This profile enables uniformly instantiating treatment Consent resources.

The Results section provides a detailed process description using a consent example.


 

 

 

Results

Consent Forms

We collected 21 treatment consents from five health care facilities in Arizona. The facilities provide inpatient, outpatient, behavioral health, and telemedicine services. Any information related to the health care organization was removed from the consent forms.

Broadly, the consents can be categorized into 6 template consents (Consents 1–3, 10, 13, 19) and 15 complete consents (Consents 4–9, 11, 12, 14–18, 20, 21). We define template consent as complete if a specific treatment/s was filled in each space. For example, Consent 1 covers diagnostic procedures/sedation and/or treatment. In the context of the consent, an open space is provided for providers to fill in with specific procedure/s. We define complete consents as those lacking open spaces: they can be specific with one single treatment (Consent 9, Consent for newborn hepatitis B vaccination), provide a finite list of procedures (Consent 5, consent for anesthesia services, with checkboxes for eight anesthesia services available), or cover a broad spectrum of treatments without the need for specification (Consent 12, Consent for medical treatment).


 

Consent for Treatment Framework

The proposed Consent for Treatment Framework for pediatric consent forms ([Table 1]) was derived from certain state legal consent requirements and the 21 consent forms.

Table 1

Proposed consent for treatment framework

Attribute

Cardinality

Definition

Consent forms

State law

Accompanying adult

(0…*)

Permission given to adult relatives to accompany the pediatric subject when receiving treatment

X

Consent delivery

(1..1)

The way the consent is delivered, including in-person, telephone, teleconference, email, or fax. Depending on the delivery type, additional information may be captured. For instance, phone number used to obtain consent by telephone

X

X

Consent type

(1...1)

The grantor can provider written or oral consent

X

X

Date/time

(1..1)

Date and time when the consent is granted[23] [26]

X

X

Grantee

(1..*)

To whom the permission is granted; an organization or professional with the required credentials, such as a clinician, with permission to perform a treatment[27]

X

X

Grantor

(1..1)

Individual giving consent under a set of permission rules, such as being of legal age. Grantors may be patients, patient's relatives, or legally authorized persons appointed by a court to care for individuals who cannot care for themselves. The person for whom a legal representative is appointed could be either minor children or adults who are considered incapacitated[22] [27]

X

X

Organization

(1..1)

Institution the consent is associated with

X

Subject

(1..1)

Pediatric subjects or patients are infants, children, adolescents, and young adults up to a certain age (depending on the applicable regulation)[12] [26] [27]

X

X

Translator

(0..1)

The individual who supports the grantor by translating the consent from one language into another

X

Treatment

(1..*)

Identifies the treatment/s being consented to. Treatment is described in its medical name or patients' words[10] [22] [27]

X

X

Treatment benefit and risk

(0..*)

Potential risks and benefits associated with the treatment permission. Providing risk and benefit assessment is part of the legal obligation for the Grantee to provide treatment. This is also related to the fact the provider must allow the patient to consider this treatment or to turn it away[14]

X

X

Witness

(0..*)

Is the individual that confirms the identifying parties, Grantor and Grantee. In many cases, the witness is a legal obligation

X

Note: For each attribute, cardinality, definition and source (consent forms and/or state law) are provided.


Our literature review yielded 68 papers, seven of which were relevant.[12] [15] [22] [23] [24] [25] [26] The remaining four papers were retrieved using snowballing.[10] [11] [14] [27] We indicated if an attribute was introduced/used before in the literature for the retrieved papers.

[Fig. 3] demonstrates how the Consent for Treatment Framework was applied to Consent 1. This consent is used for pediatric consent for diagnostic procedures, sedation, and treatment. The Grantor can be the Subject or a legal representative in this consent. The legal representative can take the role of a Witness. The Grantee is the physician who will perform the treatment. For the Treatment attribute, the form describes the procedure to be received. For instance, the SNOMED CT code 72641008 corresponding to sedation therapy could be selected. Treatment Benefits and Risks are provided, and a Date/Time is required. The form does not provide the option of listing a Translator. Consent delivery can be done in person or by telephone, so the Consent Type can be oral.

Zoom
Fig. 3 Mapping of Consent 1 into the proposed Consent for Treatment Framework.

The evaluations of the proposed Consent for Treatment Framework with pediatric consent forms (Annex 1) are summarized in [Table 2].

Table 2

Application of the consent for treatment framework to 21 pediatric consent forms

Attribute

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

Accompanying adult

N

N

N

N

N

N

N

N

N

N

N

Y

N

N

N

N

N

N

N

N

N

Consent delivery

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Consent type

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Date/time

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Grantee

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Grantor

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Organization

1

1

1

1

1

1

1

1

1

2

2

3

3

3

3

4

4

4

5

5

5

Subject

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Translator

N

Y

N

Y

Y

N

N

N

N

Y

Y

N

N

N

N

N

N

N

N

N

N

Treatment

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Treatment benefit and risk

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

N

Y

Y

Y

Y

Y

N

Y

Y

Y

Witness

Y

Y

N

Y

Y

Y

Y

Y

Y

Y

Y

N

N

N

N

N

N

N

N

N

N

 

Application of the Consent for Treatment Framework

The practical exercise of mapping pediatric consent forms into the conceptual framework revealed some unique features of pediatric consent.

Accompanying Adults: They may be designated to bring the minor for medical treatments. Consent 12, a general treatment consent, addressed parents' permission and definition of the minor's care team.

Grantors: Four consents (Consents 7, 9, 12, 13) had narratives directly addressing the parents as Grantors, indicating the caregiver's responsibility for the minor's care. The patient could not be a Grantor. For 17 consents (Consents 1–6, 8, 10, 11, 14–21), the pediatric consents could be generalized to adults who may or may not have the capacity to consent. However, pediatric treatment consent is more complicated than consenting for an incapacitated adult. For example, when caring for a child, multiple caregivers may participate in the action of care: nannies and relatives might accompany the minor for medical treatment that only the parents have the authority to consent to.

Unfortunately, none of the consent documents we analyzed included patients' assent for treatment. The lack of assent may be because it is managed outside of the consent document, but further study needs to be done to confirm.

Similarities found between pediatric and adult research consents include:

Consent Delivery: Consents 1, 2, 5, and 6 allowed consent delivery through telephone. For the other consents, the consent delivery was assumed to be in person.

Consent Type: When Consents 1, 2, 5, and 6 are delivered by phone, the consent type is oral. For all the other cases, the consent type is assumed to be written.

Date/Time: Fifteen consents had multiple dates/times to accommodate the timestamps associated with signatures from the Grantor, Grantee, and Witness.

Grantee: Twelve consents had a Grantee that was clearly expressed. Often, the Grantee was not explicitly mentioned, such as Consent 3. In this case, it is assumed that the Grantee is expressed implicitly within the hospital's context. Additionally, the Grantee and the person explaining the procedure can differ (Consent 13). One consent (Consent 6) had multiple Grantees.

Grantor: In 15 consents, the Grantor was the patient. In 20 consents, the guardian or legal representative, and in 13 consents, it was a family relative.

Subject: While all the consent permission relates to a patient, the patient was, in most cases, implicit (see Consent 1 depicted in [Fig. 3]).

Treatment: Not all consent forms specified the Treatment for which the consent was requested. Six consent forms provided the option to indicate the Treatment at the time of consent (Consent 1 in [Fig. 3]). Two consent forms (Consents 5 and 17) had checkboxes for the different Treatments. Eight forms were very broad and only provided general descriptions of the Treatment, such as Consent 12, which mentioned “Consent for Medical Treatment.“ For 10 forms, the Treatment descriptions were specific enough to identify their SNOMED CT codes (such as General Anesthesia [50697003]).


 

Mapping of FHIR Consent Resources into the Consent for Treatment Framework

[Table 3] provides details on the mapping of the attributes from the framework into FHIR resources. [Figs. 4] and [5] provide details on the FHIR treatment consent profile in different formats: logical view and shorthand definition.

Table 3

Mapping of attributes of the consent conceptual framework into Fast Healthcare Interoperability Resources elements and types

Framework attributes

FHIR element

Type

Accompanying adults

Extension

RelatedPerson

Consent delivery

Extension

code

Consent type

Consent.category

code

Date/time

Consent.date

DateTime

Grantee

Consent.grantee

Practitioner

Grantor

Consent.grantor

RelatedPerson

Organization

Consent.controller

Organization

Subject

Consent.subject

Patient

Translator

Extension

Practitioner

Treatment

Consent.provision.code

Coding

Treatment benefit and risk

Extension

Coding

Witness

Extension

RelatedPerson

Abbreviation: FHIR, Fast Healthcare Interoperability Resources.


Zoom
Fig. 4 FHIR Treatment Consent Profile logical view. FHIR, Fast Healthcare Interoperability Resources.
Zoom
Fig. 5 FHIR shorthand definition of the treatment consent profile. FHIR, Fast Healthcare Interoperability Resources.

 

Walk-Through Example: Mapping of FHIR Consent Resources into the Consent for Treatment Framework

This section demonstrates the proposed mapping by providing a walk-through of digitizing Consent 1 ([Fig. 3]) and turning the response a grantor provided into an FHIR Consent Resource based on the architecture presented in [Fig. 2].

Step 1: Manual Modeling of Consent Form to FHIR Questionnaire

The goal of Consent 1 is to record that a grantor has consented to a specific practitioner conducting one or more treatments on the patient. This form was digitized into an FHIR Questionnaire resource ([Figs. 6] and [7]).

Zoom
Fig. 6 Logical view of the FHIR Questionnaire resource representing Consent 1. FHIR, Fast Healthcare Interoperability Resources.
Zoom
Fig. 7 Excerpt from the FHIR Questionnaire resource representing Consent 1 in JSON. FHIR, Fast Healthcare Interoperability Resources.

In [Fig. 7], each question on Consent 1 (i.e., an input field) was modeled as a Questionnaire item with a unique identifier recorded by the attribute “linkId.” Each item has a “type” attribute that determines the data type of the input. For example, an item of type “reference” indicates that the input will have to be a reference to another FHIR resource (e.g., a Patient), and an item of type “coding” indicates that the input will have to be a code (e.g., a SNOMED code).

The “definition” attribute records the rule for automated mapping of the answer to each Questionnaire item to an attribute in a different FHIR resource, in this case, a Consent resource. By specifying to which attribute in the target resource each answer should map, the Questionnaire resource can specify how to automatically extract an FHIR resource (i.e., consent in our case) from the QuestionnaireResponse. The extraction process will be discussed further below. For example, the input to the “procedures” item was mapped to the attribute “provision.code” in an instance of a Treatment Consent profile ([Fig. 5]).

Step 2: Questionnaire Rendering

A web/mobile application was used to render the FHIR Questionnaire resource into a web form for users to interact with and enter information. The rendering application takes each question in the Questionnaire resource and creates a suitable visual representation in a web form with which the patient can interact to provide an input/response. For example, a question with a choice between three different procedures can be rendered as a drop-down menu with the three options populated for the patient to choose from. The developers of the rendering application have a lot of room for innovation to facilitate the grantor's understanding of the consent form and assist the grantor with true informed consent, for example, by adding audio or video content, displaying the meaning of terms by hovering over the word, links to resources, etc.

The Questionnaire rendering component is usually part of a more comprehensive Consent Management application that enables grantors to open, navigate, submit, view, or revoke their consent. There are several consent management apps from different vendors, but we used a custom app that is being developed by the research team[28] and based on the LHC-forms library.[29] [Fig. 8] shows a screenshot of a rendered web form based on the Questionnaire depicted in [Fig. 7]. In this screenshot, a web form shows the consent to the administration of the sedative for the patient James Doe, by the practitioner Dr Bob Williams, which is signed and agreed to by the patient's legal representative Jeff Smith. This is a snapshot of the form as viewed by Jeff Smith, the patient's representative, who has the legal authority to sign this consent. The term legal authorizer of consent used by the original consent form corresponds to the patient's legal representative, who is the grantor.

Zoom
Fig. 8 Screenshot of the rendering of the FHIR Questionnaire resource representing Consent 1. FHIR, Fast Healthcare Interoperability Resources.

Note that some of the text values on the right-hand side are prepopulated based on the context of the consent collection workflow and are rendered as read-only so that the user would not have to provide them interactively. For example, when Jeff Smith views this web form, the practitioner and patient's names and the procedure are prepopulated by the administrator who initiates the consent collection workflow. Similarly, the date and time of the execution of the consent are autopopulated by the rendering software and are displayed to the user as read-only.

Step 3: Response Capture

The consent management application captured the grantor's responses as a QuestionnaireResponse resource ([Fig. 9]).

Zoom
Fig. 9 Except from a sample FHIR Questionnaire resource capturing a sample response to Consent 1. FHIR, Fast Healthcare Interoperability Resources.

Step 4: Extraction of the FHIR Consent Resource from the Response

The final step consisted of extracting an FHIR Consent Resource from the raw responses captured and recorded by the FHIR QuestionnaireResponse resource. For this, we relied on the “$extract” operation defined in the FHIR SDC Implementation Guide.[30] This operation used the response items in a QuestionnaireResponse resource to fill in another FHIR resource, in this case, a Consent resource.

The values in the “answer” attributes of the QuestionnaireResponse were mapped to the Consent resource attributes, automatically based on the instructions provided in the “definition” attribute of the items in the Questionnaire resource. [Fig. 10] shows an excerpt from the Consent resource resulting from extracting values from the QuestionnaireResponse in [Fig. 9] and based on the mapping instructions depicted in the Questionnaire resource in [Figs. 6] and [7].

Zoom
Fig. 10 Sample FHIR Consent Resource extracted from the sample QuestionnaireResponse resource shown in [Fig. 9]. FHIR, Fast Healthcare Interoperability Resources.

Note that we have used FHIR extensions to record the witness and translator for the consent since these attributes are not directly supported in the FHIR Consent core definitions. These extensions are defined by the profile ([Figs. 4] and [5]). [Fig. 11] shows the logical view of these extensions.

Zoom
Fig. 11 Logical view of the extensions defined to record witness and translator.

 

 

Discussion

Our work introduced a Consent for Treatment Framework that is implementation and organization-agnostic, and supports compliance with the state legal consent requirements, and could help standardize the design of machine-interpretable pediatric consent forms.

Compliance of Consent for Treatment Framework with State Consent Requirements

Eight attributes in the proposed framework correspond to state legal requirements for general consent. Additional consent requirements may be required depending on the treatment, who is performing it, who is receiving it, and how they are receiving it. Specific surgical, invasive diagnostic, anesthesia, or other significant procedures/treatments that involve substantial risk are regulated by additional state regulations. For example, in Arizona, a general consent for pediatric care would not be sufficient to perform surgery on a child, and additional consent would be needed.[31] Also, another consent is required in Arizona to receive care via telehealth.[32]


 

Application of the Consent for Treatment Framework

The practical exercise of mapping pediatric consent forms into the conceptual framework revealed meaningful lessons.

Pediatric treatment consents required modeling the subject's lack of consent rights (i.e., newborn or minor) and parents' permission and definition of the minor's care team using the attributes Accompanying Adults and Grantor). Unfortunately, none of the consent documents we analyzed included patients' assent for treatment.

In general, there were multiple Dates/Times to accommodate the timestamps associated with the Grantor, Grantee, and Witness signatures. For simplification, we only modeled one Date/Time that should reflect when the consent is considered in effect. When the Grantee was not explicitly mentioned, we assumed it was the organization. Because the Grantee and the person who explains the procedure can be different, there could be a need for an attribute to capture who is explaining the consent. Identifying a single Grantee in some instances was difficult. A decision to pursue a Treatment is made between the ordering physician and the patient. Still, the proceduralist also participates in the consenting process, making them an additional acting Grantee.


 

Integration with Consent Management

This paper mainly focused on modeling treatment consent using the FHIR Consent Resource. Capturing, recording, and maintaining consents often call for a larger-scale Consent Management System that handles a wide range of requirements, from interacting with the patient to storing consents in the appropriate form and making them available for access by any services where consent decisions should be considered.

One aspect of Consent Management that remains a future direction for research is integrating consent management with the administrative workflows and care planning to explore when and how the prompt to collect consent from a patient should be sent.

Moreover, modeling such workflows in FHIR (e.g., using the Task resource) and the interplay between such workflows and the architecture proposed and discussed in this paper is a further area of research and requisite in achieving a comprehensive digitization model for consent in treatment.


 

Separation of Consent Management and Enforcement

The FHIR Consent Resource recognizes two different attributes, “manager” and “controller,” that correspond to the “consent manager” and “consent enforcer” roles, respectively. The consent manager is the entity in charge of capturing, recording, and maintaining consents, whereas the “consent controller” is the entity that ensures the consent rules are honored and enforced in all applicable contexts. For simplicity, in our model, we assumed that the consent manager and controller are the same entity and chose to record the organization in the FHIR Consent “controller” attribute ([Table 3]).


 

Limitations

While the proposed Consent for Treatment Framework supports compliance with certain with Arizona consent to treatment requirements, it does not support compliance with state patient rights, including the age and situations when minors can consent to medical treatment, cognitive capabilities of the patient, etc.

Another limitation is the sample size of the analyzed consent forms and the focus on community urban hospital pediatric services. Our study did not cover advanced treatments in pediatrics like genetic testing, oncology treatment, or end-of-life palliative care. Our research did not include consent forms from rural settings.

Pediatric assent was not documented in pediatric consents in general pediatric care. The documentation of joint decision-making might have occurred in special cases, but it was outside the scope of our study. Further discussion, policy, and practice changes are needed to examine the need to document pediatric assent for general pediatric care.

Furthermore, improving the education and engagement of patients with low health literacy on the effects of consent treatment permissions remains an open problem; our framework does not resolve that issue.[33]


 

Future Work

The external validation of the framework with pediatric organizations outside Arizona remains a future work. We also left integrating multimedia resources or CDS systems (a hook as called by the FHIR CDS specifications[34]) into electronic consent forms as future work. Those integrations may allow the practitioner or the patient to view the side effects and ramifications of the treatment procedures and possible treatment alternatives and provide custom and patient-specific insight that could help with a more informed decision.[35]

Additionally, CDS rules could be created to help with the design of pediatric treatment consent forms that follow state policies and laws, which may differ in consent requirements based on treatment type (e.g., abortion), minor age (e.g., older than 12 years old), etc.[6] [36]

We plan to extend this systematic analysis to the study of consents for research to assess the expressivity of the FHIR Consent Resource. We will mimic the approach presented in this paper and access a large dataset of research consent forms publicly available through ClinicalTrials.gov.[37]


 

 

Conclusion

Using a systematic approach, our work introduced and validated an implementation-agnostic, Consent for Treatment Framework to standardize and digitalize pediatric consent forms and support compliance with the state legal consent requirements.

The proposed framework was then used to demonstrate the suitability of the FHIR Consent Resource to model pediatric medical treatment consent directives.

Health care organizations can apply the shared open-source code and FHIR implementation guideline to standardize the design of machine-interpretable pediatric consent forms and generate FHIR-based executable models.[38]


 

Clinical Relevance Statement

Health care organizations can apply the shared open-source code and FHIR implementation guideline to standardize the design of machine-interpretable pediatric consent forms and generate FHIR-based executable models that support interoperability and data sharing.


 

Multiple-Choice Questions

  1. How many attributes were used in the proposed Conceptual Framework to specify pediatric consents?

    • 1 to 5

    • 5 to 10

    • 10 to 15

    Correct Answer: The correct answer is option c.

    Eight attributes were used in the proposed framework.

  2. What are the main characteristics of the proposed Conceptual Framework to model pediatric consent?

    • Is implementation agnostic

    • Has been validated with real-life consents

    • When mapped to FHIR, it is machine interpretable

    • All the above

    Correct Answer: The correct answer is option d.

    The framework is implementation agnostic, has been validates with real-life consents and has a FHIR-based, machine interpretable specification.

  3. Did FHIR have the expressivity required to model pediatric consents?

    • Yes

    • No

    • Unclear

    Correct Answer: The correct answer is option a.

    FHIR showed to have the expressivity required to model pediatric consents for treatment purposes.


 

 

Conflict of Interest

None declared.

Note

This study does not engage human subjects. The Arizona State University Institutional Review Board deemed the research exempted.


Supplementary Material


Address for correspondence

Adela Grando, PhD
ASU Health Futures Center
6161 E Mayo Boulevard #319, Phoenix, AZ 85054
United States   

Publikationsverlauf

Eingereicht: 07. Januar 2024

Angenommen: 18. März 2024

Accepted Manuscript online:
20. März 2024

Artikel online veröffentlicht:
08. Mai 2024

© 2024. Thieme. All rights reserved.

Georg Thieme Verlag KG
Rüdigerstraße 14, 70469 Stuttgart, Germany


  Lizenzen und Reprints
Zoom
Fig. 1 The methodological approach consisted of proposing and validating pediatric consent forms, a Consent for Treatment Framework, and mapping it into FHIR consent resources. FHIR, Fast Healthcare Interoperability Resources.
Zoom
Fig. 2 Modeling consents using FHIR resources; adoption of the Consent for Treatment Framework and interplay of FHIR consent artifacts—Questionnaire, QuestionnaireResponse, Consent Profile, and Consent. Dark boxes represent FHIR artifacts; gray boxes refer to other artifacts not modeled directly as FHIR resources. FHIR, Fast Healthcare Interoperability Resources.
Zoom
Fig. 3 Mapping of Consent 1 into the proposed Consent for Treatment Framework.
Zoom
Fig. 4 FHIR Treatment Consent Profile logical view. FHIR, Fast Healthcare Interoperability Resources.
Zoom
Fig. 5 FHIR shorthand definition of the treatment consent profile. FHIR, Fast Healthcare Interoperability Resources.
Zoom
Fig. 6 Logical view of the FHIR Questionnaire resource representing Consent 1. FHIR, Fast Healthcare Interoperability Resources.
Zoom
Fig. 7 Excerpt from the FHIR Questionnaire resource representing Consent 1 in JSON. FHIR, Fast Healthcare Interoperability Resources.
Zoom
Fig. 8 Screenshot of the rendering of the FHIR Questionnaire resource representing Consent 1. FHIR, Fast Healthcare Interoperability Resources.
Zoom
Fig. 9 Except from a sample FHIR Questionnaire resource capturing a sample response to Consent 1. FHIR, Fast Healthcare Interoperability Resources.
Zoom
Fig. 10 Sample FHIR Consent Resource extracted from the sample QuestionnaireResponse resource shown in [Fig. 9]. FHIR, Fast Healthcare Interoperability Resources.
Zoom
Fig. 11 Logical view of the extensions defined to record witness and translator.