Lately, I’ve been describing the standards process that we’re engaged in – making a difference to people’s health through defining healthcare IT standards – as a process that has 3 legs. Kind of like this:
Finding out whether you’re really friends
Well, not really. It’s actually 3 legs of a journey. The 3 legs are:
Developing the base standards
Profiling the standard for particular communities
Driving Solutions into production in the market
#1 Developing the Base Standards
The first leg is developing the base standards the define the capabilities for describing and exchanging healthcare. These base standards enable all sorts of communities to form around exchanging healthcare data.
But given the breadth of healthcare, and the variety of processes, jurisdictions and business rules – along with the fact that there’s no single authority of these things (in as much as there’s any authority at all), these are platform standards: they create platforms that are used in all sorts of different ways. They define how things can work.
They’re also limited in that they can only make hard rules that everyone in the world agrees to – which is a lot less than an particular set of rules that a single solution needs. So they don’t define particular solutions, except in the rare case that everyone in the world agrees to the solution (we actually might have a couple of those things: consumer healthcare repository, and terminology service).
#2 Profiling the Standard for Particular Communities
Once the international platform specification(s) exist, particular communities find common use cases for which they need to determine and record their business rules, and converge on a common approach for using the platform standards. These are called various things – profiles, templates, value sets, reference sets, implementation guides. But in all cases the basic steps are the same:
identify the need for a particular solution
form a smaller community around it
support the community to converge and agree on a particular approach
publish the approach and help the community test it’s validity
iterate the process
The principle is simple: a smaller communities can get more agreement amongst themselves because they have more in common (and are sometimes empowered by hard rules/regulations/laws – when they are useful)
There’s lots of organizations working in this space. Some relevant in the FHIR eco-system:
IHE (this is the classical space owned and brought into focus by IHE, from RSNA and HIMSS)
National Standards Organizations profiling FHIR / v2 / CDA
National Snomed Release centers (among other things they do)
etc (lots)
Aside: Platform vs Usage
Note that the demarcation line between leg #1 (platform) and leg #2 (usage) is grey. I think of XDS as a platform standard, even though it’s technically profiling other standards. Thing is, that’s what FHIR does too, and it’s very definitely a platform standard. The question is far more about community and process than technology, and XDS has played out more like a platform standard (though it’s not that important which it is)
At first encounter with the standards process, many people challenge the value of the platform/usage split – why not just get it right in the first place? We’d love to – but the trade-off between community size and level of agreement is a hard external fact we can’t wish away. Given that, if you don’t create the platform/application split, the result will be a shattered standards system with myriads of incompatible standards, one for each variation of the use case and all incompatible. Which is (unfortunately) too much like what we have now. 😒 It’s really nice the first time you solve a problem, but the next time you solve a related problem…. then you start to feel the pain. After the Nth time… you really want a platform standard.
#3 Driving Solutions into production in the market
Once you’ve formed a community, got your agreements, published them, and tested that it’s possible… you’re still not done. You created capability, and expectation. But at that point, nothing is actually working (except for limited demonstrations at hotels and exhibitions, typically).
Driving the solutions home – the last leg of the journey – that’s actually the hardest part of the journey. IT solution providers (vendors, usually though not exclusively) are often happy to collaborate in a community process, and demonstrate cool stuff to sell, but bringing stuff to market involves messy processes like certification, sales, deployment, contracts, and many people have to sign off on the process and someone has to fund the deployment/testing/maintenance.
This is the primary source of the Gartner Trough of Despair, and we’re certainly hearing that this the case with FHIR:
The platform standard is doing well – 4th release, normative, lots of energy and adoption spreading like wild fire (sorry)
There’s plenty of projects around profiling / usage agreements from IHE and others. In particular, the Argonaut project has created a huge potential in USA with access to EHR data
But – case in point – actual argonaut end-points are not widely available, and getting access to them, even when in production, can be very difficult
HL7 has pretty much no leverage over the 3rd leg of the process. IHE has more, but not as much as everyone would like. Argonaut, in their smaller community, has more again – but still not enough. Classically, the agents that have influence/leverage over the 3rd leg are the regulators (hello CMS, ONC and the NPRM), but professional societies such as HIMSS and HISA also have influence, since their membership is much more provider based.
HL7 and the FHIR community are starting to pay much more attention to the whole 3 legs, and looking to work much more pro-actively with critical partners like IHE, HIMSS etc to see what we can do to make as much as possible real.
A couple of FHIR community members asked me about what specific FHIR related events are happening at HIMSS 2019. Here’s the list of things I know about:
11:15 – 12:00: FHIR Implementations for Personal Connected Health – Hall F, Booth 9000
12:20 – 12:50: The Argonaut Project and HL7 FHIR – HL7 Booth 4849
1:00 – 2:00: Sharing SMART on FHIR Apps among VA and Other Healthcare Systems: Promise, Challenges, and Solutions – W304E
2:10 – 2:40: HL7 FHIR Update – HL7 Booth 4849
Friday
12:00 – 1:00: FHIR Interoperability: Point-of-Care Healthcare Apps in the Real World – W304A
Also, on Tuesday- Thursday:
10:15 – 5:15 (Every 15 minutes after the hour): Da Vinci Vignette – Interoperability Showcase, Booth: 9100-49 – Demonstrating Da Vinci CRD and DEQM, and Argonaut Scheduling Implementation Guides between Payers and Providers
I’m sure there’s others, and as people let me know about them, I’ll update this post. If you know of them – let me know by email (or on the social stream on chat.fhir.org)
Labeling an element MustSupport means that implementations that produce or consume resources SHALL provide “support” for the element in some meaningful way. Because the base FHIR specification is intended to be independent of any particular implementation context, no elements are flagged as mustSupport=true as part of the base specification. This flag is intended for use in profiles that have a defined implementation context.
For this reason, the specification itself never labels any elements as MustSupport.
This piece of metadata is principally defined so that applications can say, in their formal descriptions of their functionality that they support a particular element. This is different to making the cardinality 1..1, so that the element must always be present.
The goto example for this element is LMP for a female patient (commonly collected on admission and particularly before xray etc for safety reasons), but obviously not applicable for many patients due to gender or age. Note, btw, that in FHIR this would be an Observation with a LOINC code of 8665-2, and cardinality / must-support is not so simple. Never the less, it’s common to have elements that can’t be mandatory, but which systems need to support, and where it is appropriate to claim support (middle name is another good example).
It’s a little less obvious how to use must-support when writing implementation guides. Concerning this, the FHIR specification says:
When a profile [labels an element as mustSupport=true], it SHALL also make clear exactly what kind of “support” is required, as this could involve expectations around what a system must store, display, allow data capture of, include in decision logic, pass on to other data consumers, etc
In the simple case, must-support could mean that a system must store and display the element if it’s present. But profiles could go a lot further than that, particularly in the case of profiles orientated towards decision support.
The problem for profile authors is that there’s quite a lot of things to say about using elements, and must-support is a single boolean flag. Some profiles have gone to public comment and there’s been some argument about how the fine details work. So…
The first thing to remember is that must-support is a computable flag to help rendering engines highlight an element to human readers. It doesn’t have more significance than that. For example, there’s no validation hanging off it. A human has to look at the written documentation and determine what the significance is – whether writing automated test cases (e.g. TestScript), user acceptance tests, or implementing systems. So the most important focus is to get the documentation correct.
Must-Support is primarily a visual cue. I’ve never heard any discussion about implementers not having to read the documentation of all elements (though, of course, no one reads documentation if they can avoid it anyway), so not setting it doesn’t make any genuine difference.
So overall, the best thing I can say is, “chill”. (now watch the comments show a complete lack of chill…)
Dark Helmet: What the Hell am I looking at?! When does this happen in the movie?!
Colonel Sandurz: “Now.” You’re looking at “now,” sir. Everything that happens now [indicates himself and Helmet] is happening “now.” [Indicates the screen]
Dark Helmet: What happened to “then”?
Colonel Sandurz: We passed “then.”
Dark Helmet: When?
Colonel Sandurz: Just now. We’re at “now,” now.
Dark Helmet: Go back to “then”!
Colonel Sandurz: When?
Dark Helmet: Now!
Colonel Sandurz: Now?
Dark Helmet: Now!
Colonel Sandurz: I can’t.
Dark Helmet: Why?!
Colonel Sandurz: We missed it.
Dark Helmet: When?!
Colonel Sandurz: Just now.
Dark Helmet: … When will “then” be “now”?
Colonel Sandurz: Soon.
Recently, a request came up in Pharmacy to determine how best to model the request to take a medication immediately and then follow that up with a regular schedule. As the Pharmacy Workgroup dealt with the request, we realized that this wasn’t a Pharmacy-specific request. There are many times in healthcare that something needs to happen “NOW” and the means of representing “NOW” needed to be something non-Pharmacy-specific.
The obvious first place to look for representing “NOW” is the Timing datatype. Within that datatype, the ‘when’ code data element seems like the obvious place to represent “now”. Simply adding a code of “NOW” to the EventTiming value set seems like it solves the problem. We gain the use of the ‘offset’ data element to say “Do X 5 minutes from NOW”.
The problem of adding a code of “NOW” to the EventTiming value set is that “NOW” just doesn’t seem to be an event like the other codes in this value set. If you look at the set of events, every one of them is something that occurs and can eventually have a specific point in time assigned to it. “NOW” isn’t like that. If you read the excerpt at the beginning of this post, you can see the problem with NOW. Every point in time either was NOW, is NOW, or will be NOW. So what does “NOW” as an event mean? It would be the one code that isn’t like the others.
I can’t see any other way to represent the general concept of “NOW” other than the option above, but I might be missing something. I’d love to hear about alternative ways of saying “Do X NOW”.
The My Health record is a noble idea but the standard they chose is from 1995, it uses PDFs, it’s not computable, it is just digitised paper,” he told News Corp Australia
Technically, the MyHR is a document repository where the repository uses a modified variant of XDS (for the ‘personally controlled’ bit) and the documents are all CDA documents. A small number of the CDA documents are simply wrappers around PDF documents (<5%) but the rest are full CDA documents with variable amounts of coded data embedded in them (some quite comprehensive indeed).
In spite of the fact that it’s a repository of CDA documents, most of the commentary in the media describes them as PDF documents, and John’s comments reflect that – based on what people told him while he was here.
So if the repository is full of CDA documents, why all the commentary about PDF? Actually, the answer is pretty simple:
Consumers (patients) cannot get the CDA documents; all they can get is a print out of the presented part of the CDA document – that is, in effect, PDF (and probably is literally PDF, if they print to PDF)
Aside: I’m not sure why it would be such a problem for consumers to get their own data, but this is a long standing prohibition
Clinicians can download the CDA documents directly to their systems, and the systems are able to extract the data from the CDA documents. But mostly, this doesn’t happen (for a variety of reasons), and all the clinician gets is a presented view of the CDA document, just like if it was PDF
The purpose of the system was to collate data, but the lack of solid data and clinical agreements have made that very hard to do, and the collation views that are offered are less useful than first intended – so they’re not very high profile. More generally, the system doesn’t support integrated data based work flows – it mostly behaves like a repository of PDF documents
Finally, the public (and journalists, and politicians) have an inherent understanding of PDF (all of us read them, and many of us produce them), and use imprecise language with regard to standards . “PDF-like” quickly transits to just simply “PDF”. This even happens in the general healthcare IT community
I’ve given up trying to dispute the language – programmers and analysts working directly with the system know better, but since the system mostly functions like a repository of PDF documents, I think there’s bigger things to focus on.
But if you like precision in your language… the MyHR is a CDA based system, not a PDF based system.
During my talk, and in regard to how to move forward in regard to Interoperability, healthcare it, the MyHR, and the continued use of faxing in Australian healthcare, I spoke about the need for us to have courage. Today, as a follow up, someone asked me:
“What kind of things should we do to have courage?”
Here’s my top 3 ways that we should act with courage in Australia.
1. Have the courage to speak the truth, and say unpopular things.
Note that this not excuse for being rude, or causing trouble. Nor is it ok to ‘speak the truth’ without first investing time to make sure it’s the truth. But if it really is the truth, we should say so, even if it’s unpopuler. And there’s a strong view right now in Australia that people need to toe the party line. In regards to healthcare IT, that’s hurting us right now.
An obvious corollary to that is not to punish people for speaking the truth – even if you don’t agree it’s the truth. If they’ve made a good faith effort to find it, then open discussion can follow
2. Have the courage to recognise when you fail, and do something else
To many of us get ‘locked in’ to past choices – it’s a variant of the sunk cost fallacy. Particularly when it’s group activity. How does your department/company/professional society look at projects and decide they’ve turned into a death march? Is the bar to kill a project lower or higher than to create one? Do you have any evidence that you broke the sunk-cost pattern any time?
And don’t think that everything you do will succeed either. If you think it does, then either you’re not trying hard enough, or your analysis is not objective enough.
3. Have the courage to change how you are accountable to other people
Providing healthcare is a team game, a rich complex eco-system with 1000s of specialties. The real challenge with healthcare interoperability is not getting computers to talk to each other, but getting people to change their behaviour when technology and IT means there’s better ways to do things – different kinds of accountabilities between the players in the team.
Too often, change is too hard. Even something as simple as using faxes – a constant theme of the day yesterday. There’s no technological reason to use faxes; they’re risky, and costly, but we still are using then extensively – because of human factors. The reaction of our international guests to that discussion (and the MyHR) was revealing: astonishment at the discussion we were having.
Things aren’t going to change unless we have courage. But too many people who listened to me yesterday heard my call to courage as intended for someone else other than them. But you can’t change someone else, only yourself. You, reading this blog, ask yourself:
HL7 owns the “FHIR” ® trademark (along with the FHIR flame icon). While the specification itself is licensed under Creative Commons Public Domain, and can be used in anyway possible, the Trademark is not public domain; HL7 defends the trademark carefully.
What that means is that anyone can use the term “FHIR” to refer the FHIR specification – that’s called nominative use – it’s naming the thing that FHIR identifies. Note that HL7 asks that people use (R) along with the FHIR mark, at least once). But if an organisation uses the word “FHIR” to refer to something of their own, this is not nominative use, and they require written permission from HL7 to use the trademark in this fashion.
All these refer to the FHIR specification that HL7
publishes. On the other hand, these uses, where FHIR refers to something the
organisation is doing, require written permission:
Acme, Inc is proud to announce FHIRMachinePlus,
our new interface engine
Acme, Inv invites you to Acme-On-FHIR, our new
seminar about…
HL7 grants written permission to organisations to use the FHIR trademark if the organisation making the application is using the mark in a way that is clearly an application of the standard, and that explains how they intend to ensure conformance/consistency with the specification. We do this to allow the community to grow and identify itself, and create findable artefacts using search engines. We’ve issued close to 100 trademark use permissions. (Btw, you can apply for written permission at http://www.fhir.org/, and since that doesn’t cost anything, you can apply even if you’re not sure that you need trademark approval).
It’s become clear, as we administer the trademark application
process, that some clarifications are needed. Firstly, two clarifications about
the existing system:
We do not, and will not, issue approvals to use
the FHIR trademark in a company name
We do not, and will not, approve the use of the
FHIR trademark in another registered trade mark. E.g. we might approve the use
of FHIRMachinePlus, but FHIRMachinePlus could never be a registered trademark
in it’s own right
Revision
Further, the current system is under revision. We are
considering changing our current system to add further conditions around the
use of the trademark. Specifically, we are considering only issuing trademark
approvals to HL7 member organisations, and only for limited periods (that due
to ongoing legal advice). Having said that, we recognise that:
There might be a mismatch between the registered
member and the organisational unit using the trademark, or it might be being
used by a consortium
Open source projects can’t be members, but we do
want to approve them
Once organisations start using the trademark
they can’t stop using them, so HL7 needs to be a faithful partner in this
regard
None of these changes are yet made; we’ll be consulting our members for their opinion; HL7 owns the FHIR trademark for the benefit of its members, and it’s their value that we are figuring out how to maximise . This is just a heads up that the member consultation is coming.
Note : FHIR® is the registered trademark of HL7 and is used with the permission of HL7.
I’m very honoured to make a guest today from Mike Morris, who I met at the HL7 FHIR Applications Round Table in Washington DC a couple of weeks ago. Mike is a cancer patient who is using FHIR improve his own treatment.
Cancer
Rears Its Ugly Head
October 18, 2014. I’ll never forget that date. We all have one of those. For me it was waking up from a colonoscopy to
find a doctor hovering over me. “You
have stage 4 colorectal cancer”. I
asked if I was going to die. “It doesn’t
look good” and then he walked away. The
doctors gave me six months to live. I’m
going to die? Nobody wants to die. I had a choice to make do I want to live or
die? I wanted to live.
They decided to put me in the chemo
chair right away to try and reduce the tumors.
My cancer originated in my rectum and had aggressively metastasized to
my liver and lungs. After four chemo
treatments they decided the tumors were too big and decided to operate on
me. February 13, 2015, Friday the 13th,
and it was going to be my lucky day! I
went under the knife for 15 hours while they removed 2/3 of my liver, ¼ of my
colon and the large tumor in my rectum.
I bled so much during the operation that I almost died. But somehow, I survived. I lost 30 pounds, had a bag coming out of
stomach, and spent 2 weeks in the hospital trying to recover. It took me a whole week before I could get
out of the hospital bed and take a lap around the ward. It was tough.
But so am I. I had to keep fighting.
As I started down the road to recovery,
the cancer continued to be aggressive. Doctors
put me back on chemo before my strength returned from the surgery. I battled the cancer through 12 rounds of
chemo during the summer of 2015. It was
hell. You walk into the infusion center
and you can see that most patients have lost their will to live – they have
lost all HOPE. I think when life turns into non-stop chemo
treatments every cancer patient starts to wonder, is it worth living this life
of constant pain and struggle? I wanted
to come out the other side! I wanted to
do it for my kids! I wanted to do it for
myself. I’ve got to do it for ALL cancer
patients out there. How can we turn the
tide and empower cancer patients with a better outlook on life? I wondered, how do we fight for better
treatments and better outcomes for those that don’t have a voice? Or for those who don’t know there are other
options out there for them than the dreaded chemo chair. The chair saved my life but at the cost of a
tremendous amount of physical, emotional and psychological pain. Most cancer patients must feel this way, and they
either give up or fight. I wanted to fight.
How
Can I Survive? What Can I do to Cure
Myself?
There must be something I can do with
my technological background and the cancer treatments I have endured. I am a cancer patient, technologist, and patient
advocate. I graduated Stanford in 1993
and was lucky enough to jump right into the most exciting time in Silicon
Valley, right when Netscape 1.0 browser came out and we were all trying to
figure out how to code HTML. I started two
successful consulting firms and had the opportunity to build amazing teams that
deployed monitoring software for datacenters.
Our customers were Apple, Tesla, Novartis, Merck, HP and others. We gained a tremendous amount of experience
and it was fun.
Then cancer hit. Now what do I do? Suddenly working in data centers didn’t seem
that interesting. I wanted to work on
the health care problem. I saw all the technical
issues during my cancer fight – data siloed in different EHRs, CDs/DVDs of my
scans somewhere else and an industry that STILL likes to use fax machines and
emails to get things done. It is
archaic, these technical issues must be fixed if I am going to survive my
cancer. If I can’t get to my data, then
how can my healthcare team possibly treat me if they are working blind? The problem must be solved.
Why not use all the technical skills I
learned in the Valley and use them to create an integrated health dashboard for
cancer patients and solve the problem?
Why not monitor and manage patients in near real time – why do we have
to wait 2 weeks for the 10-minute appointment we get with our oncologist. Why not look for treatment options other than
chemo and give cancer patients HOPE
that there are alternatives to dying from chemo toxicity.
The picture below depicts the standard
chemo cycle every cancer patient goes through. Notice how there are gaps in care once
treatment is given and you go home?
There is minimal monitoring of the patient and almost no data captured
on a patient’s condition during a chemo cycle.
This is one of the challenges that we cancer patients face. How do we stay out of the ER when chemo
toxicity sets in and we have go to the ER?
My white blood cell count was so low in January 2018, I had to go to the
ER, chemo destroyed my blood counts.
Every person that came to visit me in the hospital during that time had
to wear a Hazmat suit because my risk of infection was so high. If I caught a virus I would likely die because
my body had very low levels of white blood cells to fight off any
infection.
Figure
1: Protocol Treatment Chemo Cycle
The
Road from Protocol to Personalized Treatments
Back to the summer of 2015 and my
chemo cocktail stories. After 12 rounds
of chemo I had developed sores in my mouth and I couldn’t eat. I was DONE with chemo. I didn’t want protocol chemo treatments anymore. I was looking for other options. I was looking for personalized medicine. I didn’t want to see others suffer as I have
over the last 4 years. I went through
countless chemo treatments, surgeries, procedures, etc. What if we could provide personalized care
based on a patient’s own tumor and cure them?
This is where cancer treatment is going.
The problem today is many providers do not offer personalized care and
payers are not yet willing to reimburse expensive genomic tests. Further compounding the problem is that technology
hasn’t yet caught up. We are still
facing issues with getting our data and dealing with privacy concerns and risk. Why doesn’t a system exist so I can see all
my data and work with my oncologist to come up with a personalized plan via
dashboards? Not fax machines and
emails. Why should I have to login to five
different systems to figure out where my data is and how to make sense of it? What if I want to share my data with someone
else…why can’t I do that easily? I
quickly became depressed when I realized that the integrated health system that
I was looking for simply didn’t exist.
So, I figured…why not build it? I decided to use all the technical skills I
learned. Instead of monitoring servers
and applications in a datacenter, why not monitor chronically ill patients? I started with myself since I didn’t have to
worry about privacy concerns. I got my
own data and shared it with my own consent.
I decided it had to be done, so I quit the consulting company I founded
10 years ago and created Curesoft. The
goal was to develop an Integrated Patient Portal that provides not only an
integrated health record but also proactive monitoring and management of the
patient via intelligent alerts. If I get
all my data in one place, then my oncologist should be able to see trends and
alerts that give more insight into my cancer and what is happening in my
body. Is the treatment working? Why do I have to wait two months for a scan –
can’t the data tell us whether its working BEFORE I get scanned? Time is everything to a cancer patient who
doesn’t have time. It had become clear
to me, this was my life’s mission. At
Curesoft we would build a system to help cure my cancer for a start. And, in doing so, if we can provide the same
tools/data to other cancer patients, let’s do it! In the end, if we can help save lives and
give cancer patients HOPE – that’s
what it’s all about.
Breaking
Down the Siloes
On the technical side, it’s been
traditionally very difficult to integrate with healthcare systems. Large vendors such as EPIC and Cerner have
built their products as more of a billing and scheduling system not a health
management system. APIs were not an
important feature in terms of creating interoperability across siloed
EHRs. What we need is an integrated
platform where all my data is consolidated and available to me in near real
time.
Today it is possible to break down the
EHR siloes by leveraging standards that have developed over the past few
years. FHIR is one important standard
that the community has worked hard to define and now technologists can
implement to get data out of EHRs. Utilizing
other standards such as oAuth we can now create integrated applications that are
data driven based on patient consent.
Privacy is a big issue. The
patient must be in control of their data and authorize consent to those they
would like to share their data with. With
FHIR, we can now integrate multiple vendor systems (e.g., EPIC, Cerner,
AllScripts, etc.) on behalf of the patient via consent to create an integrated
health record. FHIR resources are
returned via API calls to a REST endpoint which sits on top of an EHR.
At Curesoft we’ve been able to integrate
my data from 5 different EHR systems and consolidate them into one view (see
below). I almost cried when I saw all my
data from Oct 18, 2014, when I was diagnosed with cancer, through today all in
one place, across multiple providers. I
finally had my data in one place!
Figure
2: My Integrated Health Record
I now realize what the power of having
your own data really means and the potential benefits to all cancer patients
(or really any patient):
More time with my
doctor, less time looking for data (manual and across systems)
Better patient
outcome and more personalized experience – shift from protocol to personalized
treatments/techniques such as genomics based on my tumor
Predictive
outcomes – utilizing big data and machine learning we can start to predict outcomes
Stay out of the
ER – caregivers can manage patients more proactively through real time
dashboards alerts/events. This will keep
people out of the ER.
Unlock siloes and
increase efficiencies – take siloed EHRs and consolidate data into an Integrated
Health Record (IHR). Save time by having
all the data in one place
One important aspect of FHIR is that
it is a technical solution to unlock data from different healthcare
systems. But what is needed is a
business solution on top of FHIR. Without
knowing what data you are looking for, it becomes an exercise of getting the
data and then trying to figure out what to do with it. The data loses its value unless you harness
and focus in on what data is important. In
my cancer battle, I’ve focused on critical metrics that my oncologist needed. That way I could filter out the noise and
the rest of the data that was not relevant to my cancer.
In my case, I was able to ask my
oncologist what she looks for in the data when we meet after a treatment
cycle. “Bilirubin, ALP, AST,
platelets, and WBCs” she said. “I can
tell you whether a treatment is working based on whether these metrics trend up
or down over time.” This was the
key: if I could harness all the data
around these critical metrics, could I provide a view to my oncologist that
would be useful? The answer is yes! Through the Curesoft app we were able to
trend these metrics over time and correlate them to the treatments I was going
through. My oncologist was taking a data
driven approach to figure out the efficacy of the treatment. All in near real time.
Figure
3: Correlation of Data to Personalized
Treatments and their Outcomes
I’ve recently undergone personalized
treatment with Panituma, a targeted drug for Colorectal cancer patients. The dashboard above shows the treatments (T),
scans (S) and other timeline events captured out of multiple EHRs. The timeline event data is correlated with ALP
data which measures liver function. ALP
was used as a marker for me as many tumors continue to metastasize in my
liver. What you can see on the dashboard
is around April 2018. My ALP levels were
trending up which is not a good sign. It
meant that my liver was processing tumors that were growing. After the targeted treatment was applied
around July 2018, the ALP data was trending down. This was a clear sign that my tumors were
shrinking and that the treatment was working!
After four treatments with the targeted drug, I was scanned and what we
had seen in the data was confirmed: the
drug worked, and my tumors shrank. This
is an excellent example of how big data and correlation back to treatments will
help us understand treatment efficacy.
It will also allow my oncologist to possibly course correct treatment in
the middle of a cycle vs. waiting for the next scan.
Genomics: The Next Frontier
Data doesn’t stop with EHRs. Wearables, APIs and Genomic data are all
other types of data that can be pulled in to enhance our integrated health
record. Genomics has received a lot of
positive press because it is an effort to bring personalized care out of the
labs and into the hands of patients. The
next wave of personalized treatments will come from genomics and the analysis
of each cancer patient’s tumor.
Treatments today are largely based on protocol which is typically
chemo. But what if we could determine
from our own cancerous tumors what mutations exist and what other treatments
are available based on the genetic makeup of MY OWN CANCER? Very powerful!
My oncologist and I decided to order a
liquid biopsy test to find out if there were any other options for me as we
move forward with my ongoing cancer battle.
Liquid biopsy tests are done by a blood draw and are preferred by
patients vs. standard biopsies which typically involve procedures where you are
sedated and spend a day at the hospital.
Traditional biopsies are the gold standard today. However, liquid biopsies are quickly gaining
ground and traction in terms of accuracy and ease of use (blood test vs.
procedure).
Figure 4:
Liquid Biopsy Results – Gene Mutations
We used Guardant Health as the company
that provided the testing analysis and results.
They looked at over 100+ cancer genes in my tumor and found that seven
of them were mutated. With each mutation
there was a list of off label drugs that could work on my particular
tumor. In addition, the report
referenced several clinical trials that I could apply for including name, phone
number and location of the trial. This
is personalized medicine. These are
treatment options given to me based on my tumor results. This gave me tremendous HOPE that I now had an army of options at my disposal and that I
didn’t have to live a life of chemo!
Every patient should have access to
this kind of personalized data. The
challenge today is that payers are not willing to reimburse for these tests
until other treatment options, such as chemo, no longer work. I decided to pay out of pocket for my test
after the insurance company denied my claim.
If it’s going to help me cure my cancer, then I’ll pay. But it sure would be nice to have it covered
by the payer. Maybe someday…
Figure
5: Liquid Biopsy Results – Clinical
Trials
My Cancerversary is coming up on
October 18th, 2018. It will
be my 4th year battling this terrible disease. I consider myself lucky to still be
here. They say that 11% of Stage 4 Colorectal
cancer patients don’t live more than a year.
For some reason I have been able to stay alive through the countless
chemo treatments (30+), surgeries, radiation/Cyberknife, and now targeted
drugs. And now new exciting treatments
are coming out every month. Immunotherapy
and CAR-T cell therapy are already showing huge signs of progress and have
cured patients in some cases. You must
hold on long enough and survive until these treatments are available for your
type of cancer. I am confident that the
silver bullet will be there soon for all of us.
To my fellow cancer patients out there
– continue to fight and never give up!
It all starts with owning your data.
We have a right to our data so ask for it! Empower yourself with your data. We can beat this! We WILL
beat this! It’s only a matter of
time. Strength, focus, love, HOPE, that’s all we need.
