The Standard

Weclome to CodeX's New Patient Voices Series!

CodeX recently talked with cancer patients, survivors, and advocates to hear their stories and learn more about their perspective through the cancer care coordination process. CodeX (Common Oncology Data  Elements eXtensions) is a HL7 FHIR Accelerator, launched at the end of 2019, that is building a community to enable interoperable cancer data modeling and applications that lead to step-change improvements in cancer patient care and research.  

How is the Standard of Care Defined?

“Everyone just said this is the standard of care!” Today, Desiree D. has no evidence of disease, but in 2017 she was diagnosed with stage 2b breast cancer at the age of 40. When trying to make decisions about her course of treatment, Desiree was repeatedly told by doctors that she was getting the standard of care. In reality, the “standard of care” is relatively loose terminology. When making treatment decisions, Desiree felt that the standard of care where she was living in Virginia meant something different than the standard of care in Massachusetts or the standard of care in Vermont. 

Imagine if a chef could not make a soup because he only understood Portuguese and the soup’s instructions were in Hindi. The chef could look elsewhere and find a solution after further research; however, the lack of a common language has cost the chef time and the chef’s soup is not going to be the same as he wished. This scenario is harmless, but a similar and much more serious situation exists across healthcare systems. The healthcare industry remains significantly less standardized than other industries. This means that treatments for the same type of cancer might vary greatly by geographic location, cancer center, and even oncologist in part because healthcare data is not collected or shared in a standard manner.

Weclome to CodeX's New Patient Voices Series!

CodeX recently talked with cancer patients, survivors, and advocates to hear their stories and learn more about their perspective through the cancer care coordination process. CodeX (Common Oncology Data  Elements eXtensions) is a HL7 FHIR Accelerator, launched at the end of 2019, that is building a community to enable interoperable cancer data modeling and applications that lead to step-change improvements in cancer patient care and research.  

Bias in Healthcare is Deadly

“It’s almost like negligent homicide. Because of the bias that’s there—whether it’s explicit or implicit—is resulting in these people—patients of color—not receiving the full scope of care that they should be.” Jamil Rivers is a person with breast cancer and the Founder of The Chrysalis Initiative.

The Chrysalis Initiative is a patient advocacy organization looking to disrupt harmful disparities in accessibility, quality and outcome of cancer care. Looking at the source of disparities is the first step to rectifying them, and The Chrysalis Initiative provides equity assessments that evaluate all types of healthcare services that offer cancer care. The assessments evaluate whether the experiences of patients of color differ from White patients. When Jamil first started the equity assessments, she expected around 50% of patients of color to experience racism and bias. However, Jamil quickly discovered that this number was much higher. “90% of our preliminary data indicated that they [patients of color] were receiving substandard care and experiencing racism and bias in their care.” According to Jamil, many medical providers and researchers are cognizant of racism and bias affecting patients, but few understand the true pervasiveness of explicit and implicit racism in patient care. Even biases that at first glance seem trivial can be deadly because each action based upon bias deteriorates the quality of care a patient receives.

Report from Virtual FHIR DevDays 2020 on the Patient Innovator Track

Initiatives seeking to expand the use of HL7’s Fast Healthcare Interoperability Resources (FHIR®) standard were highlighted at the recent HL7 FHIR Dev Days 2020 virtual event.

The Patient Innovator track included four presentations highlighting its recent move to encourage the use of technology to support patient involvement in care. HL7’s Patient Empowerment Work Group has a mission of promoting and amplifying the viewpoint of patients and caregivers in HL7’s standards work. Its initial priorities include enabling patients to correct errors in records, contribute their data to records, plan care, and efficiently gather and store patient consents.

The four presentations were judged by a panel of HL7 experts for their use or projected vision for the use of FHIR to solve problems in patient empowerment in healthcare. In addition, attendees at the virtual Dev Days event could vote to award one of the participants a People’s Choice award.

 The HL7® FHIR® Connectathon Consumer Centered Data Exchange Track

Covered entities face an ever-growing demand to enable digital health apps to access Protected Health Information (PHI). The technical and legal requirements to enable this are the focus areas for the Consumer Centered Data Exchange (CCDE) track at the HL7 FHIR Connectathon. This track initiated at the San Diego Connectathon (September 2017), and it made more progress recently (January 27-28) at the New Orleans Connectathon. Track participation may have been piqued by Apple’s recent announcement that it will provide patients an “effortless solution bringing health records to iPhone”, and that Apple will use FHIR services to enable this.

Caption: Participants at the HL7 FHIR Connectathon 17 in New Orleans, LA. Image credit: Kai Heitmann.

Apple’s announcement couldn’t be more closely tied to the work of the enthusiastic CCDE track participants, representing the entire healthcare industry including providers, payers, government, academia and app developers. Apple could benefit a lot from this track’s work if iPhone users are to access PHI from covered entities beyond the initial 12 participants of the iOS 11.3 beta.

Why? Mainly because the CCDE track focuses on 3 key requirements:

1. It should be technically simple for a covered entity to verify that an app requesting access to a patient’s PHI is indeed controlled by that particular patient;
2. The way an app accesses PHI should be compliant with data governance and privacy policies of the covered entity, as well as HIPAA guidelines, and;
3. The experience of an app user should be simple enough so that they clearly understand and acknowledge what they are sharing with the app. 

 The HL7® FHIR® Connectathon Consumer Centered Data Exchange Track

In my previous article, Patient Consent Forms: Redundant in the World of OAuth, Part 1, I suggested providers to design their OAuth2 authorization challenge as a patient consent form so that patient consent can be digitally recorded during the OAuth dance. This would allow providers to share patient health records with the patient health apps much more efficiently without requiring separate paper/PDF consent forms, while still meeting the policy and regulatory requirements.

In this post, I will walk through a specific example of how to do this, and also discuss the differences in providers and patients’ perspectives on consent.

OAuth2 Authorization Challenge as a Patient Consent Form

First, let’s consider the scenarios from the Consumer Centered Data Exchange track at the FHIR Connectathon 16 in San Diego where a patient app can pull their health records from all of their providers in one place, or cause their EMR data to be sent from provider A to provider B. In both these scenarios, the provider may need an explicit patient consent or authorization form (often paper-based) signed by patient. So, how can we use OAuth2 challenge instead to capture patient consent?

 The HL7® FHIR® Connectathon Consumer Centered Data Exchange Track

The HL7 FHIR Connectathon 16 in San Diego hosted a Consumer Centered Data Exchange track, focusing on scenarios where a patient app can “pull” their health records from all of their providers in one place, or cause their EMR data to be sent from provider A to provider B. However, before such pulling or sharing can begin, one needs to consider that a provider may require an explicit patient consent or authorization form (often paper-based) signed by the patient

Today, a patient would typically do this by signing a paper form and the provider would hand over a DVD containing scanned PDF copies of the patient’s health records. Now, imagine using a consumer health app on your phone, and every time you request your provider to share your records, the app asks you to first download a consent form that you then need to print, sign and fax to your provider. That would be a cumbersome and undesirable patient experience. Instead, digitally embedding patient consent during the electronic pulling or sharing of patient records itself can make this experience much smoother.