A Reference Architecture for Digital Health: The Health Catalyst Data Operating System

A Reference Architecture for Digital Health: The Health Catalyst Data Operating System


Hi friends. Thanks for joining us today. Looking forward to being very transparent
about this journey that we’re on and give you an update on the progress we’ve made the
last couple of years with the data operating system and be so bold as to suggest that it’s
a reference architecture. I believe for the future of digital health
in creating a data platform that can store and manipulate and provide access to data
that I think is fundamentally important to the future of the healthcare. Let’s dive into these slides. The storyline today starts with a reminder
about the fundamental vision and concept behind the data operating system. It really is our vision to create a single
platform for supporting the three fundamental data missions that we all wrestle with today. That is analytics, workflow applications,
and data interoperability and portability all in one platform. The reason that I advocate this as a CTO and
CIO, chief analytics officer, whatever title you want to give me is that among other things. It creates a consistent layer of data for
all of the missions with a single platform. I think those of us that are being in the
trenches of healthcare IT know that having these on disparate platforms, these three
missionaries creates a lot of inconsistency and data and data sharing. There is a little bit of an evolution here
if you’re around in the ’80s and ’90s when we were connecting everything in the healthcare
system with HL7 messages. Now the industry is dominated by a single
platform electronic health records. I think that we’re headed towards the next
evolution of that and taking that concept of a single platform and the benefits of that
to a broader used case and a broader number of missions. Think of the evolution of this similar to
what we went through from best of breed, disparate data stitched together with HL7 going towards
a single platform in an electronic health record. We’re going to do that again in analytics
with full applications and interoperability, and portability. The other benefit to this as a tightfisted
CIO who had to manage all the money and the cost associated with managing these different
disparate systems. I believe we can achieve a much lower total
cost of ownership by having a single platform that supports all of these, also creating
agility around data. TCO is a big part of this as well. We’ll give you an update on how are we doing
relative to this vision. Then, I want to be very transparent about
the mistakes and lessons that we’ve encountered along the way. These slides are going to be a little bit
more marketing oriented that I typically try to achieve with these webinars. I’m not really selling Health Catalyst friends. I mean it’s going to come across as though
I am. What I’m really selling is the lessons that
we’ve learned and the reference architecture so that everyone can openly learn from that
criticize it, whatever you want to do with it. It’s not so much about selling Health Catalyst. It’s about just selling and sharing the knowledge
and the lessons. Okay, I want to go through a couple of slides
here that many of you have probably seen before just to constantly reinforce the message. The origins and the data operating system
go back to this cartoon that I’ve been carrying around with me now since about 2008. I would say that this cartoon represents the
health data ecosystem that a patient should benefit from. For the most part, we’re working in the lower
left quadrant of this cartoon right now and the claims, and the healthcare encounter data. We’re not even taking full advantage of the
data that’s in the space. We’re making very limited progress in the
rest of the clouds. Our digital understanding of the patient requires
this entire data ecosystem. Also, everything about interoperability and
portability. Eventually, what we want is for patients to
have the ability move and interact with this data freely on their own. Data sharing right now is stuck down here
in the healthcare encounter data, but we want to broaden the vision of that to the entire
cloud of healthcare related data that’s required for a patient’s optimized health. Then, we want a patient to be able to analyze
that, inform themselves and move that from care provider to care providers as necessary. We’re just beginning the digital journey and
we’re laying down a foundation for DOS to accommodate all these different data sources
and analytic used cases. I used this slide to metaphorically describe
the state of where we are right now and the pixilated view of the truth that we have in
healthcare. This is a picture of my family, our little
girl, little boy, my wife up in Yellowstone this fall. That’s the true picture of my analog life. Were analog creatures in our existence. This is healthcare’s digital view of my life
right now, so it’s highly pixilated. In order to round out the pixels and the precision
of understanding, we have to start adding data in the rest of the cloud and especially
in those times that I’m not visiting a healthcare encounter. I’ll talk a little bit about its fundamentally
digital sampling problem. That those of you who haven’t been around
digital sampling, you might go back and brush up on its fairly simple concepts. We only collect data on patients generally
speaking about three and a half times per year in the US. The most data intensive environment we have
is the most unfortunate data environment, which is the ICU. We’re trying to avoid ICU encounters to the
degree that we can, but it’s the most data-intensive environment that we have right on healthcare
and that’s not good enough. We’re only sampling patients data and their
profile about three and a half times per year in the US and that’s just not enough. The other problem that we have in healthcare
is that we’re largely collecting qualitative billing data. In ICD code, even though we call it discrete
is really qualitative data. Lab values, genomic test and vital signs are
quantitative data. My background in the air force, the National
Intelligence Communities, we were all about quantitative data, bathing satellites and
rockets, and missiles, and weapon systems with sensors to collect the telemetry that
we needed to manage those systems. That’s the mindset that we need to have going
forward is bathing the patient in bio-integrated sensors. They were collecting data on those patients
beyond the four walls of the three and a half clinical encounters per year. There are I would say four strategic options
for healthcare digital platform right now. This is how I would look at it if I were still
a practicing CIO, CTO. I could build my own, which I’ve done a bunch
of times. I don’t care to ever do it again. Frankly, I got tired of building my own and
maintaining my own, which is the genesis of health catalyst is to create a commercially
viable alternative to building your own. It’s not financially scalable to do that. If you look at the early adapters and advocated
of data warehouses and healthcare, a lot of those now homegrown systems are coming up
a glass against the glass ceiling of cost and financial scalability. I would say that we’re somewhere in the similar
stages as we were with homegrown EHRs in the 2000s. All of the homegrown electronic health records
at Intermountain, Vanderbilt, Columbia. Those are pretty much all gone now. I think Beth Israel and John Halamka are the
last folks to hang on to theirs and credit to them for doing that because it’s a very
capable system. I think we’re at a point now where homegrown
data warehouses are just frankly fall by the wayside because they’re not scalable. Of course, it’s on companies like Health Catalyst
to make those alternatives viable and attractive and better than what you could build on your
own. EHR vendors of course are in this space now. I would say that EHRs only represent one of
dozens of required data sources. While, I have lots of respect for Epic, and
Cerner, and Allscripts, and all the hard things that they’ve achieved over the last few years,
the reality is the cultural and technical legacy, and the skills gap that EHR vendors
have in the analytic space, and I would say the broader platforms space of digital health
is going to be hard to overcome. You could choose one of the splashy big data
silicon valley vendors and startups. I think we see a lack of healthcare expertise
and data knowledge being a real detriment to that option. I think a lot of the splash and appeal that
they had a couple of years ago has faded because of that. It’s pragmatically those splashy Silicon Valley
startups have not had the impact that we all hope they might. Then, there’s Health Catalyst and similar,
Apervita, Innovacer are two, I would even put dimensional insights probably in that
category. They’re similar to Health Catalyst. Generally speaking, they have more modern
technology, deeper data skills, and they tend to be agnostic to data sources. It doesn’t matter what data can be loaded. Those are the four strategic options and what
I would suggest is the slides that I’m about to go through, you can hold the reference
architecture that we have with the data operating system up against these other options. Ask those other options. Build your own EHR vendors, Silicon Valley,
how well they line up against this reference architecture. That’s where we’re headed. Just a reminder about the healthcare analytics
adoption model, we publish this a number of years ago. We since gave it away with no obligations,
no connection to HIMSS so John Daniels and James Gaston, and the friends at HIMSS analytics
now have the ability to come into your organization and assess where you are operating. I just added a ninth level to this, which
is direct to patient analytics and artificial intelligence. I think that’s where we should all head and
sail. In general, what we’re trying to do with the
data operating system is move the scarce resources that organizations have up the chain of value
from working it down at the lower levels, wrangling data and data models, and trying
to standardize vocabulary and patient registries. Let’s get folks out of those lower level duties
and start moving them up into the higher levels of this bottle. This is another way to assess the options
that I previously mentioned is to ask each of the options, the vendors, build your own,
what’s the plan and what are your abilities to meet the requirements in each of these
levels. Ask EHR vendors. Ask Health Catalyst. Ask the splashy Silicon Valley startups. What are you doing at level two to standardize
your vocabulary? What are you doing at level three and four
to automate all these painful compulsory measures? What are you doing to help us reduce waste
and care variability? What are you doing in pop health et cetera? Use this as a reference architecture to, and
a checklist to explore your options and build your strategy. Then, finally, as we deploy and mature the
products, the roadmap should support the continued escalation of skills up the levels of value
here. That’s high level of what we’re trying to
achieve with the operating system. I would suggest that you might want to do
the same and take the same approach into your local strategy. All right, so I’m going to give you the reference
architecture all in one big bite here. Then, I’ll build the slide bite by bite in
the next slide. I want you to think about this in two halves. Everything to the left of my cursor here is
essentially plumbing and infrastructure that we’ve spent somewhere around $96 million to
build out. That’s again the scalability issue that I
think most organizations will never be able to achieve the level of investment that we
put in this to automate it is just significant. Now, I’m probably not replicable across the
industry. Everything to the right of this then becomes
the very differentiating value that you can derive from a platform like this with data
to the masses, how you get data out to the edges of the organization? How do you build specific more workflow applications
off of this data together? Then, finally what are you doing with a platform
to enable client developed analytics in third party apps. The open API is required to do that. That’s the all in one bite. Now, let’s build the slide out a little bit
at a time and I’ll talk about each piece of it. All right, so we know that there are somewhere
around 2,000 potentially compulsory measures in the industry right now. It’s a nightmare to manage those. We’ve built a product that we call measures
manager. It’s a content manager and system for viewing
and managing all of the measures that you need to track and requirements of those in
one place. If you’re out there in the trenches of healthcare,
you know that most of the time, this is managed right now in spreadsheets and databases quite
often. It’s hard to keep up with changes especially
those mandated by payers and federal government. We’ve automated the movement of those eCQMs
from CMS into measures managers so our clients don’t have to do that anymore. We also provide an opportunity and a tool
here for you to manage and document your own measures requirements, so that there’s a consistent
place to go and your quality folks, your finance folks, your data analyst, all know and understand
working from a common definition. It’s a really important data governance tool
and really important way to stay consistent with your analytics and accurate with your
analytics as well. Oops, let’s go back here. Let’s build this slide out. There we go. Right now, we work with about 300 … a little
more than 300 different data sources and healthcare. On average, each of our clients right now
has about 20 to 50 data sources that they ingest into the platform. The more mature clients have somewhere in
the neighborhood of 75 to 100 different data sources. Again, going back to the challenges that I
think EHR vendors will have in this and as well as the build your own, and the splashy
Silicon Valley options is someone in the organization, someone in those other options is going to
have to build out those connections to those data sources. Have an understanding of a data model, have
an understanding of simple things like change data capture, and incorporate that all into
a scalable affordable platform. We spent a lot of time and money on the ingestion
of data and the understanding of those data models. I think again it’s a very hard thing for the
industry to replicate that. There’s just not enough money to continue
investing like we have. One of the things that’s also different about
our approach to this is we ingest text as a natural part of the data pipeline. Traditional data warehouses didn’t deal with
text, but we believe it’s fundamentally important to blend the discrete data in those sources
with the text that’s available. Land that all in the DOS data lake. Let me comment on this box right here, the
flash data engine. A lot of people will say, “Well, gosh, why
did you build your own data engine? Why didn’t you use a product like Informatica?” As a tightfisted CIO who had to pay for those
kind of tools in the past, I said, “I don’t want our clients to have to pay for an Informatica
license or similar product. They’re just too expensive. They’re too horizontal. They’re not tailored for healthcare. Let’s build our own and just bundle that in
the platform.” By doing that, you’re saving several hundred
thousand dollars per year in licensing and support fees. Again, that’s another thing. I just said, “We’re not going to support that. We’re going to have our own.” We’re going to keep all of this nicely coupled
and emigrated in one platform. We’d land all the data in the data lakes essentially
untouched, untransformed. Then, we start peeling data and subsets of
data out of that data lake into what we call subject area marts. This tool, part of the flash data engine supports
the development of subsets of data. They’re unique to analytic use cases. I’ll go a little bit greater detail into it,
some of those analytic use cases here in a second. Another tool that we built and coupled with
this is a product we call IDEA and it stands for Instant Data Entry Application. With the recognition that there’s always missing
data in those source systems that you wish you had or there’s data in those source systems
that’s not exactly computable. IDEA is a product that we developed that augments
what I call the white space of data that exist over here on the left side of the diagram. This turns out to be a very pragmatic tool
for augmenting the data content in the data lake and one of the most popular tools that
we have. It’s a very pragmatic common sense way to
add data content and essentially function as what I think traditionally we’ve used chart
abstractors to achieve. The other thing that we’ve done here that’s
fairly unique is we’ve made AI and data science a natural part of the data pipeline, so that
the data scientist and the data architects, and data analyst are now working together
as a team. Data scientist have the ability to publish
their models in the infrastructure and our data architects and data analyst that may
not have that deep data science expertise can invoke those models as a natural part
of the data pipeline. It lowers the boundary for adoption of AI
and data science. It also by creating what I call the citizen
data scientist, but it also creates a dev ops environment for the support and ongoing
evolution of those models, which if anyone wants to brush up on their skills of the future,
figuring out how to apply application development. Dev ops concepts to AI and data science is
going to be a critical new skillset that hasn’t quite worked its way out yet. It hasn’t matured to the degree that it needs
to. Once you publish these models, it’s really
important to create a dev op support infrastructure for checking on them. Making sure the models haven’t degraded and
constantly keeping them updated. We build that right into the pipeline. Again, I want everyone to think about this
and go, “Okay, well, what are we doing with our strategy, either your homegrown or vended
to meet these different needs?” Okay, so think of this as a reference architecture. We’ve also added our own tools for metadata
management and what I would call task management. Rather than buying an off the shelf product
that’s horizontal, covers all industries which is a popular one right now. We have built a product that we call Atlas
and it’s all about data governance and metadata management. The other thing that we’ve done is build our
own DOS operations consul rather than buying a product from TIBCO or one of the other monitoring
tools. Again, those horizontal tools haven’t worked
as well traditionally for healthcare data. They’re also very expensive. We’re trying to provide healthcare specific
tools to this data management environment and do that at a significantly lower price
point than what it would require to build on your own or buy on your own. All right. Now, once we start pulling subsets of data
out of the DOS data lake with the subject area mart designer, we curate some of that
data into what we call level one and level two DOS marts. At level one, we’re consolidating and we’re
harmonizing data around vocabulary essentially. Not much around data logic but around vocabulary. The typical domains of vocabulary include
clinical cost claims et cetera. At level two, now we’re starting to harmonize
and standardize content around the logic associated with analytic used cases, so sepsis, diabetes,
CHF, COPD, et cetera. We’re moving up the stack of analytic value
from vocabulary to data logic and data binding. Those we’re building out as a standard supportable
part of what we deploy with every client site, and we keep those updated and upgraded. We also have the ability still to do our traditional
lake binding and customized subject area marts as well. We will never give up lake binding entirely,
but we’re giving it up to some degree. I’ll talk a little bit more about the mistakes
that we made with too much lake binding in subsequent slides. Then, off of the curated content, we spin
off products that we call data to the edges and data to the masses meeting that mission. Overall, the marketing team calls us rapid
response analytics. The whole idea here is to get data out to
the edges of the organization as cheaply and quickly, and as accurately as possible. Population builder is very sophisticated but
super easy to use tool for creating patient cohorts, from everything from traditional
ICD-9 base or ICD-10 base definitions to genomic smears. Even allow the incorporation of text processing
into the definition of patient registries and patient cohorts. We specifically built that tool to enable
nontechnical users to build and govern, and publish their own registries and their own
cohorts. We also wanted to create an interactive tool
so that clinicians, administrators, the quality department, data analyst, data scientist could
all sit in a room together and interact with data in a very dynamic way to divine cohorts
and patient registries as they see fit. This tool also comes populated with standard
definitions from CMS and other mandated eCQMs. Leading wisely is our management and executive
dashboarding, and I would call it a Bloomberg terminal. Those of you what have been out in the trenches
of healthcare know that a lot of times, the extent of an executive dashboard or a management
dashboard is a bunch of JPEG stuck on a PowerPoint slide. I suffered from that when I was a C-level. This tool is designed to provide executives,
managers, administrators access to the data that they need in the form that they want
to see it, and the ability to interact socially around common measures where team-based approach
to improvement is important. It’s all built out in angular D3, so it’s
very supportable, very maintainable and there’s no license and fees associated with it. It gives data out to the edges of the organization
for what I call clickers for the world. Traditionally, the folks, they’re not really
interested in drilling around in data too much. They just want a quick summary. They want to be alerted about things that
are outside the boundaries of their thresholds they’ve defined. They want it to be easily accessible. Touchstone is the … think of it as the data
platform of all of our client’s data in one harmonized D identified environment. Our approach to that right now is around benchmarking
but there’s all sorts of really cool used cases for the Touchstone data. We have about 60 million patients in that
with an average of 88,000 facts per patient. We’re just going to constantly build that
out and expose that to all the benefits that it could provide to the industry. Finally, we have the ability to push all of
these analytics and data back out to the electronic health record. Think about the edges of the organization
being in the clinic in helping physicians. We can push our analytics back to EHRs, it’s
not easy, but we can do it. Some of the restrictions technically and contractually
that EHR has placed upon us make that harder than it should be. We’re working with EHR vendors to try to get
pass those barriers and try to work collaboratively together. We can push those analytics and back to the
point of care, and get data out to the edges that way. The next area is what we call data to the
domain. If you think of the upper right as broad tools
for mass access to data to the edges of the organization, the data in the lower right,
the applications in the lower right is really about specific analytic use cases. Chorus for example is an activity-base costing
system that we built to improve the ability to track cost at a more granular level. I frequently describe it as activity-based
costing at 20% of the effort but 80 to 90% of the value. It’s workload tool. Back to what is DOS all about, the upper right
is traditional analytics. The lower right is really workflow tools. We’re reading and publishing data back into
the data operating system. These are workflow applications. This isn’t just read only analytics. We also have a patient safety monitoring suite
trying to address the needs and the market for the chronic under reporting and the significance
of patient safety issues and adverse events that we all know about. We have a group of analytic accelerators. I’ll talk a little bit more about that later
and what those mean. We have a care management suite. We have what we call pop health foundations. We have a product called community health
that’s all around compulsory measures. These are very specific data to domains, very
narrow analytic domains and use cases. Quite often associated with workflow and publishing
data back to the data operating system. Then finally, we’re building all of this to
support client develop analytics in apps. We don’t want to be the only vendor in the
world taking advantage of this. We want all the good ideas that clients have
and also third party apps to take advantage of the significant infrastructure and investment
that we’ve made for the benefit of the industry. We’re building out the APIs to support that. Frankly, we haven’t built out enough of those
APIs. My team and I are not quite satisfied with
the progress we’ve made but this year, among six teams that I have this year as CTO is
the progression of what I call the DOS developer program, which will put a lot of emphasis
on client develop apps and third party apps to enable that. That’s the piece by piece description of the
different parts of the data operating system. Now, I want to just share with you again for
the sake of impact and example of all the different compulsory and internal measures
that we manage and deal with right now and that a lot of you folks deal with that we
are making as commoditized as we possibly can so that you folks can move up the chain
of value. There are some of the examples we have. There’s clearly not 2000 here but there’s
many more. That gives you some idea of all the compulsory
and internal measures that we are support with the data operating system. This is a list of all the 300 data sources
that is frankly outdated as soon as we publish it and update it. I hope by the time I retire that this list
is somewhere around 2000, which is again rounding out that cartoon that I described earlier. These are the data sets that we’re going after,
and I want to emphasize that it’s not enough to just ingest it. A lot of Silicon Valley startups and the public
cloud vendors will say, “Oh, yeah. We can ingest data. No problem. We can connect to any data source.” There’s some truth to that. I think they’re also over playing that a little
bit. What’s really important is not connecting
to it. It’s knowing how the data models are developed
where the data is stored. Knowing simple things like change data capture. That’s the hard part. It’s not about connecting to these source
systems and sucking the data in. It’s knowing what to do with it, knowing and
understanding the content, and also the pros and cons, and the gotchas that are hidden
in the data. That’s the most important thing. That takes a lot of time to build, not just
in the trenches, mistakes, learning and constant iteration that is frankly very, very hard
to replicate if you haven’t invested in it. Okay. Then, here are some of the 45 plus analytic
accelerators I talked about later in the lower right portion of the DOS diagram that we’re
putting together that are not 100% reusable because the nature of the healthcare data
being what it is, it’s impossible to make any of these 100$ reusable. On the scale of reusability, probably 70 to
80% reuse is possible. That’s a lot better than starting from scratch. Again, what we’re trying to do is commoditize
as much of this as we possibly can, so that you and your teams can move up the value chain. This slide summaries how I would look at this
if I were still a CIO trying to build one of these platforms myself. You’re looking at somewhere between three
to $12 million per year to build and maintain your own. Versus, generally speaking, in the industry,
our annual spend did clients somewhere around $1.5 million to $4 million. That gives you an idea of how far we’ve taken
the commoditization of this data operating system and enabling this kind of agility in
the market. Now, let’s get to the transparent part about
mistakes that we’ve made, and the lessons we’ve learned along the way. Here’s the high level agenda and I’ll drill
into some of the details here in subsequent slides. Care management version one, big mistake. We put too much emphasis on late binding,
Qlik and similar BI tools. Little too much emphasis on the application
GUI layer not enough on the reusable data logic layer. Back to those DOS marts that I mentioned earlier. A little too much emphasis on acute care variability
reduction when we should be spending more time and have spent more time now on preventive
care. PARMS and I’m not going to tell you what that
acronym stands for. I’ll keep you in suspense and tell you all
about how we flew past that in the last couple of years, but we’re catching up to it. Then, I’ll share with you what we’ve learned
about AI and data sciences that applies to healthcare. I also want to emphasize and talk about why
the heck would we be this transparent? Well, the bottom line is we just have humble
confidence in what we’re doing. We’re trying to help the industry. Despite the mistakes and missteps we’ve had,
we’re still ranked number one or number two by all the vendor industry analyst. We’re very grateful for that even with all
those mistakes. I joke with people and clients have joked
in full truth that this is the worst it will ever be. The good news is we’re just constantly getting
better and the momentum is building. Generally, speaking life is better I believe
when you pursue the … someday, I’m going to get this tattooed. Find the truth, tell the truth and face the
truth. It’s just more comfortable to live life like
that. Knowledge makes us all humble and arrogance
makes us ignorant. That’s what we’re avoiding. Care Management v1, man, all I can say is
what the heck were we thinking because we made mistakes in all of the classic areas. Number one, around technology. We did not build Care Management v1 on the
data operating system. In fact, Care Management got started on a
completely separate infrastructure before DOS was even conceived. That was a big mistake. We should’ve waited. We misplaced the domain knowledge that we
had. We tried to convert an app development team
that was working on internal company wellness games to the complex world of Care Management. We thought, “Well, corporate wellness is similar
to care management. Let’s just take that code and let’s take that
team, and let’s port them over to the complex world of care management.” That was not fair to them, and it certainly
wasn’t good for the product. We had an interesting culture on the original
team. The bottom line is I won’t go into the too
much of the dirty laundry here but suffice to say that fear and retribution do not make
for a success in any situation. That negative culture that we created probably
around fear and retribution of deadlines and deliverables, and things like that. That was not a healthy environment for the
team to operate in. There’s this other problem that we had, which
I call the false summit. If you’ve been in mountain climbing and grew
up like I did in small town Colorado. I’m now in Utah. You know that quite often when you think the
summit is just a few hundred feet above you, you get there and you realize it is just a
ridge. The true summit is another 1000 to 2000 feet
ahead. If you start sprinting to that summit and
celebrating, “Wow, you’re almost there.” You get to that ridge, it’s pretty disheartening. Quite frankly, we celebrated too many false
summits in the progression of the care management applications. We celebrated way too much, way too early. What that does is it relaxes you about performance. You back off and you think, “Oh, we’re already
there.” That’s just a very unhealthy place to be so
don’t celebrate until it’s time. Then, even then, celebrate for about five
minutes and then get back to work. We went back through the industry. We did cash refunds to our clients. We created better culture for the team. We added some new hires with new expertise
and care management. We’re going to produce Care Management v2
in the fall of 2019. Happy to chat and have a specific webinar
on just that topic and everything that we’ve learned and bring the current leadership into
that discussion. Too much late binding, so it’s pretty ironic
that I introduce concepts of late binding to healthcare back in 1997 borrowed from work
that I was involved in in the air force and National Security Agency. The reality is too much of any good thing
makes for a bad thing. Late binding was a noble concept at the time
but concepts are easily copied. Late bindings is not a product, it’s concept. The way we implemented it did not encourage
reuse of data and logic. It created data governance and consistency
problems for us. It also led to performance problems in our
platform because you’re proliferating all these late binding data objects. You don’t have any curated data. You just keep repopulating these late binding
data objects. Well, pretty soon, you’ve got thousands of
data objects that are requiring loads, and it just starts dragging down performance and
reliability. Our response to this is the acceleration of
our DOS marts, which are these curated data models that exist between the extremes of
an enterprise data model and a late binding data model. If you operate in either one of those two
extremes, we know that enterprise data models don’t work or not even … I don’t even hear
anybody talking about those anymore. We still want to pursue late binding when
it makes sense. We’re not going to operate in either one of
those extremes and we’re certainly going to back away from late binding on everything. Pretty significant lesson learned there. We put too much emphasis on Qlik and Tableau. They’re great products. I love them. They should be a part of every strategy of
analytics and healthcare. I would add probably power BI to that tool
belt as well. The reality is they are not suitable for every
analytics used case or user persona. Also, licensing is pretty expensive for those
tools. I’ve always advocated that in analytics, you
have to accommodate three user personas. I call those designers, drillers and clickers. A designer is the engineer, the programmer,
the SQL writer, also lower level code, Python, R, Angular, et cetera, JavaScript. Drillers are the people that want to interact
with and pivot around tables and things like that. They are great user persona for Qlik, Tableau
and PowerBI. Most of the world, I would suggest probably
70% of the world are clickers. That is those are folks, executives, and managers
in particular who want to be notified when they need to know about a threshold has been
broken. They want a link to click on to get a quick
understandable view of the data that they need to be aware of. They want to subscribe to the data that they
want to be notified about. They want to make a very quick decision and
an accurate decision. Then, they generally want to either delegate
the follow up or interact with other team members about how to achieve a positive trend
in the reports that they’re concerned about. Population builder and leading wisely those
products that I mentioned earlier are our response to that need for clickers. We’ll always offer products and accelerators
with Qlik, Tableau, PowerBI et cetera. Now, we have products to support clickers. I would suggest as you build out your analytic
strategy, you think about how you’re going to get data, in what format and what method
of expression to these different user personas and how to do that affordably. Yeah, the tools I list down below are examples
of how we’ve addressed all three user personas, while not giving up on Qlik, Tableau and PowerBI. Interestingly, we put a little too much emphasis
on the GUI of our applications. In part, because we were just stretched for
time and resources but we probably put a little too much time and effort on the GUI and not
enough on the GUTS. DOS marts and the curated data content under
the GUI is what we’re focusing on now in building that out. That’s our response to moving from GUI down
to content and providing that reusable infrastructure underneath the GUI. The truth is we put a little too much emphasis
on acute care variability. We’re still having a little bit of a challenge
letting go of this as our primary business model. We all know that optimizing prevention of
care is becoming more important. Optimizing acute care is critically important
and will be forever. I don’t want to dismiss that, but we all have
to acknowledge that there’s more to the analytic needs of healthcare that include how do you
make these clinically questionable compulsory measures that are tied to the reality of reimbursements
whether you agree with those compulsory measures or not, whether they’re a pain in the neck
or not, the reality is they’re still tied to the reimbursements. They’re still tied to status measures like
US news and world report. You have to deal with them. The goal then is to make those as hands free
and as commoditized as possible so you can spend more of your time on the higher value
levels of the analytic adoption model. We all know that managing chronic conditions
with risky health status when money is at stake, is critically important. Then, there’s opportunities to optimize shared
services like radiology, lab, pharmacy, supply chain and even marketing where they can benefit
from a platform like this. It doesn’t really have anything to do with
reducing clinical variation. It has to do with throughput, efficiency,
adequate appropriate utilization of the assets in those areas. You’ll see, and we’ve been shifting from this
acute care focus to these other areas for the last couple of years, and you’ll see more
of that going forward. Okay, to the mysterious acronym, this came
from my air force training. PARMS is what we were all about in information
systems engineering and command control communications intelligence. It stands for Performance, Availability, Reliability,
Maintainability, and Scalability. It was beat into our education and professional
training to engineer the military information systems to support PARMS. That’s why military still has information
systems around that are operating just fine and they’ve evolved for 35 years. Some of the systems that my teams and I designed
back in the mid ’80s are still around and operating. It’s because we designed those very forward-thinking
around the PARMS initiatives and the PARMS acronym. Frankly, we had a hard time changing our cultural
attitude from traditional data warehousing mindset in engineering, which is eight to
five availability is fine. DOS requires 24 by 7 availability. It’s taken us a little bit of time to change
our mindset. Well, then of course, the skillset and the
tool set have to change along with that. One of the key themes for me in 2019 is PARMS
and how we make sure that the data operating system can support 24 by 7 availability. It’s an eight to five data warehouse anymore. The other thing that’s interesting that I
would strongly advocate is that the old days of bulk data loads where you once a day, you
update your data, maybe even once a week. Those days are long gone. I’ve been saying this now for 10 years. If you’re doing bulk data loads, unless, it’s
minor, small, little data sets, you need to get rid of that. Just recognize that constant trickle feeds,
when the source systems change is the best architecture. Then, you don’t have complicated load windows
to manage. You have the opportunity of a real time analytics
and decision support. Let go of bulk data loads and that was a big
part of our culture that we’ve had to turn away from. We’re now into more real time constant trickle
feed architecture. I mentioned earlier, it’s not a traditional
data warehouse. It’s mission critical platform. We have to function like that. I mentioned earlier that late binding contributed
to poor performance. We’re backing away from that. 2019 is a year PARMS for DOS and for what
we’re doing. Okay, we’re about to end this portion of the
conversation. We’ve had some interesting lessons learned
around AI and data science. I would suggest and again, this gets back
to the big Silicon Valley vendors, Google, Microsoft, Amazon, who have incredible AI
capabilities but boy, their healthcare data and domain expertise is significantly lacking. In fact, talking to folks that are now hired
into those organizations from healthcare, the dominance of the culture is taking over
whatever healthcare domain expertise they’re hiring. They have some struggles ahead. That data and domain expertise is critically
important, probably more important now than the algorithm expertise because algorithms
are essentially becoming a commodity. Those of you who’ve been around for a while
might remember that we started the healthcare.ai community and website. That was interesting. I looked at that when we started it. Now, I wondered if we would turn into an academic
teaching opportunity, which is that’s okay. The reality is we need to produce viable pragmatic
AI models and get those out to client sites rather than trying to educate the community,
we need to deliver results to the community. That’s the best form of education. You’ll see us backing away from the time and
the money that we spend on healthcare.ai, so we can focus on execution that delivers
value to the clients. Knowing how to apply those algorithms to healthcare
is not a commodity. It’s concepts like experimental design and
research method is that really important to understand in healthcare if you’re going to
be a successful data scientist. You don’t have to be a PhD with algorithm
expertise. I would suggest you need to be fundamentally
familiar with these concepts like PICO and experimental design research methods. Even if you don’t practice those to their
fullest, you can think about them conceptually as it relate to healthcare. This is not the web environment they’re working
in. This is not rockets. It’s not cars. It’s not Silicon Valley. We’re in a very different environment and
data, and healthcare. You have to have a mental mindset about how
to approach data and healthcare that’s different than other industries. What I’m suggesting is if you want to be a
data scientist, spend your time understanding experimental design, research methods and
PICO concepts, then start building your skill set and your tool set for data science. We’re stepping back from the production of
models right now to the production of mindset. We’re really grateful that we hire Jason Jones
from Kaiser background at Intermountain and Bayer, has a PhD in biostats. Also, he’s worked operationally in healthcare
analytics, so he understands the academic side of analytics. He understands the operational side of analytics
and healthcare, and has been a great addition to the team. All right, I think that might be my last slide. It is. Sarah, I’m going to turn it to you friend. You got an announcement and then, we can take
questions and feedback. I’m happy to stay on past the hour if folks
want to continue to dialogue. Perfect. You have had a lot of questions coming in
throughout. Apologies there. We do have one disclosing poll question that
I’m going to launch before we dive into that Q&A. After today’s presentation, some of you may
want to learn more about DOS. Dale went into great depths here, but you may still have
questions about specific aspects, and you may want to know more about other Health Catalyst
products and professional services. If you would like to learn more, please answer
this poll question. We’re going to leave that open for a moment
as I pull up your questions here. We’ll just start at the top Dale unless you
see one that you want me to jump down to. Sure. Let me see here. Dee Sams asked, “Where do you see pharmacy
and pharmacist playing a role in the world of data analytics?” Well, that’s two questions I would say friends. Pharmacist are already well known for the
value they add, just the knowledge that they have about therapeutics, and the importance
that they play in a team-based approach to care. Including many countries now let pharmacist
function as what amounts to primary care physicians. They’ve increased their licensing capability. Their domain expertise, we have a couple pharmacist
for example on staff here. Their domain expertise in patient safety,
pharmaceuticals, and therapeutics is invaluable. The other part of that question is how do
you see pharmacy? Well, there’s all sorts of analytics, about
just the comings and goings on a day to day operations of a pharmacy that can help you
understand and manage the business of a pharmacy that the patient movement of pharmaceuticals,
medication adherence is critically important. We all know the medication adherence is a
problem in the industry. I guess that’s what I would say Dee is that
I think pharmacist and pharmacy-specific data is largely underappreciated right now, but
we appreciate it. You’ll see us spending more time on it in
the future. Tony Hussein asked, “Please defined your target
market for your product and reference architecture to us.” Tony, for the most part, our client-base is
made up of healthcare providers and clinics, hospitals, big integrated delivery systems. We also address small community hospitals
with our products. We now have a foothold in what we would call
the risk arbitrage or risk management market. For example, clients like Equitas Health and
Agilon that are managing risk for clinics and physician network. They’re not actually in the care provider
business as they are in the risk management business outreach and lowering risk reduction
for clients. We have growing interest from international
markets where the economics of healthcare are better aligned around reducing cost and
improving quality as opposed to the fee for service market in the US. Let’s see. What market segment am I leaving out here? I’m forgetting one I think. I think that’s all I can think of right Tony. Those are the target market. Michelle asks, “Can you mean by text processing
natural language processing?” Not really Michelle. There are plenty of natural language processing
vendors that are way better than we’ll ever be. That’s a very unique space. The way we’re approaching natural language
processing text is to provide the data as a platform, just like we are everything else. We have what amounts to text DOS marts. If you’re an NLP vendor, you can plug into
our platform. You don’t have to do the plumbing to get to
the text. We’ve already provided the text for you. You can analyze and use that text in any way
that you see fit. That’s one used case. It’s text as a platform mixed with the discrete
data that traditional data warehouses typically manage. The other used case is we’re using I would
call more simple but direct domain specific text processing and NLP, and our population
builder tool. Also, in our patient safety tool. We’ll peel off very unique used cases for
NLP in our products. Care management will be another one in the
future but we are not going to be a general NLP vendor. In fact, we want to take advantage of all
the cool things that Google and Amazon, and Microsoft are doing. We don’t want to creep into that space. We just want to be the infrastructure for
it. Then, peel off used cases that are narrow
and defined according to our client needs. Let’s see here. Let’s see. Next question, can you discuss more on the
DOS data lake structure to support enable AI? Conceptually, my definition of a data lake
is that it’s essentially a landing spot for data in its raw, high fidelity form. Literally, no transformation. You land the data there. Most of the time, nowadays, organizations
will land that data in a big data stack. Hadoop, another big data products. We can do that. We don’t do it. We haven’t felt a compelling need to do that
yet because most of the data that we deal with in healthcare right now is relationally
oriented, so it’s just easier to land it in a relational format. We’re getting into the time series data more
in the future and we’ve already tested that concept. We can load and stream that data into a big
data stack. What does it do to AI? It provides an AI platform if the data science
teams want to use that raw, untransformed data to develop models. They certainly have access to that and likewise,
a traditional data analyst want to query that data structure and data lake, they can do
that as well. What does it do to enable AI? I’m not so sure, other than it takes care
of the plumbing so that the AI and data science team don’t have to do anything to the left
to the data lake portion of the diagram. Let me scan this really quick friends to see
if there are some questions. Okay, all right. All right, let’s go to Charlene. She asked, “How is data captured in the workflow
standardize so their lines with requirements of capturing and analyzing eCQMs. So far Charlene, I think I understand your
question but so far, the data that we’re capturing in the workflow apps does not overlap with
the data that’s required for eCQMs. I get what you’re saying. If you’re collecting data in Epic or Cerner
for example to support eCQMs and then, we would collect overlapping data, how would
you reconcile that. So far, we don’t do that. Now, what idea that application that I mentioned
earlier, what it will allow for is if you’ve been around products like Midas for example. Midas will allow you to abstract data that’s
in a non-computable form in your EHR. Translate that with human being, load it into
Midas and then, submit that as an eCQM. That’s a workflow that we support with idea. In that regard, you’re pulling data in from
your EHR that may not be computable to support an eCQM. It may be just a little bit off computability
or difficult to track. Then, we can augment that in the data warehouse
and blend that together in a common eCQM data structure back at the idea app layer. Go back and we’ll share these slides. If you go back to the layer of data flow here
idea became entered into it, that’s where we’re reconciling the data. We’re not reconciling it over on the far right
hand side. By the way, I just want to mention Charlene
asks, “How about HIE state local as a target market. For heaven’s sakes, I completely left that
off. That’s when I was forgetting. Obviously, we’re in that space. Our acquisition of Medicity a few months ago
is the reason we got into that space is so that we can consolidate the platform around
the three missions of data that I mentioned, analytics, app development and interoperability
and portability of data. Yeah, my apologies for not mentioning that. We are absolutely in the HIE space. We’re going to be announcing our three-year
road map for the HIE space in the next six weeks or so. Thanks for reminding me and my apologies for
not doing that sooner. Okay, question from Shane, “Is the DOS platform
built in the cloud?” Yes, it’s built in the cloud. It’s build in Azure right now. I imagine that’s where we’ll stay but the
way we built it, we can actually afford teeny cloud vendor, so we have no love affair with
any of cloud vendor other than the one that’s best for our clients. Brent asked … Hey, Brent, “What standard
are the develop for APIs?” Darn, I knew somebody was going to ask that
question. Well, we’re supporting FHIR and we’re working
on those FHIR APIs Brent but … you know what I’ll do? I should’ve included as slide in here that
describes the API. Brent, remind me to follow up with you and maybe I’ll even put that slide
in the deck that we published out on the web to describe our APIs in greater detail. Yeah, I’ll do that. Sorry, I do not have that answer friends. Amanda asked, “Please describe your ingestion
tool set.” Well, we can ingest HL-7 data obviously. We have that HIE capability. Our flash data engine has the ability to ingest
any data content from text to streaming data. We’re constantly improving that flash data
engine. The only thing that we don’t ingest right
now, the only data type that we don’t ingest right now is images. That’s on a roadmap as well. What is the practical definition of SAM reference
architecture? Marty, think of it as a data mart. Traditionally, I think we would call it a
data mart. It’s a subset of data. That subject area mart is a term that Tom
and Steve used when they founded the company. It gets a little confusing sometimes. Just saying of it as a data mart. It’s a subset of data that we carve off the
data lake to support a unique analytic domain or a harmonized standardized vocabulary, that
kind of thing. Going through this shift, was Health Catalyst
attempting to become a lean organization? Darryl Burton asked. Well, I don’t think we were attempting that
Darryl. I think we just always want to be that. We try to practice and believe in lean. Lean to me is a mindset as much as it is a
tool set and just constantly being aware that the product is the product, the process is
not the product. I think a lot of times companies get involved
in lean and six sigma get obsessed with the methodology instead of the output. Fundamentally, lean is about empowering people
that are capable at the lowest levels of the organization to make decisions on their own
empowering clients to build their own applications. Be as agile as possible. Just remember that the process and the methodology
is not the product. The product is the product and stick to that. I could go on and on about that. I just want to call out. We are two minutes past the top of the hour. You’re still okay to move on for a couple
more minutes? I’ll just stay on as long as folks are still
on. How many do we have 150? 151. Okay, yeah. I can stay on for a little bit more. By upgrading from CAP to DOS, what improvement
should I expect with our environment from the SMD, CMD access point? Carl, that’s a great question friend. I should … boy, there’s a lot to benefit. The DOS console is better. We’ve got now a web application that’s a starting
point for their whole Health Catalyst application, environment that you probably don’t have support
for real time data, support for the native and corporation of AI. There’s all sorts of reasons for you to get
upgraded to DOS 18x there friend. Why don’t you reach out to me directly and
let’s get you lined up to do that. If I were in your shoes, I would be trying
to get off CAP just as soon as I possibly could for lots and lots of benefits, including
DOS marts by the way. I don’t know if the curated data content that
we’re building out under 18x is really valuable to all of our client. Maxine asked, “For the slide of balance between
GUI and data. GUI has pay back as less training required.” Yup, more intuitive in the past performance. Without nice GUI, no matter data we could
drill down on people, we’ll not know how to use the application. Totally agree. However, data is more important without deeper
data adhered to the application, the application means nothing. How do you like to balance the two for the
application development? Well, that’s a good question friend. I mean I think now we’re pivoting back to
the balance. We’ve invested a lot of time and money in
the GUI, which is great as you mentioned. It’s now we need to build out the data content
under the GUI so that there’s something meaningful underneath it. Just be careful about chasing features in
the GUI that sound and look cool without equally chasing function and data content underneath
it. There’s probably an art and as much as a science
to that in knowing when to find that balance and I’m happy to help out. Thanks Maxine and thanks for being a part
of the team by the way too friend. Okay, can you talk more about the difference
between drillers and clickers? We have what I think are tons of drillers. John Beasley asked that. Yeah, drillers are the folks who are … one
of the vital signs of a driller is how much they enjoy interacting with pivot tables and
Excel. If the person is an active user of pivot tables
and Excel, then they’re probably going to enjoy a driller experience. They’re probably going to appreciate a product
like Tableau, PowerBI and that kind of thing, and Qlik. That’s the vital signs that I would look for
John is if they have the skills and they tend to interact with Excel a lot, and they’re
drilling around in pivot tables and that sort of thing. They’re probably a driller. I also want to say that I’m the kind of person
that interacts at both levels. As a CTO, I’d really like to have core analytics
and measures pushed out to me in a clicker mode. There are times when I’d like to drill and
interact with data at a deeper level. In my tool belt as you address me as a client
in your organization, as a customer in your organization, you just ask them question about
how they want to interact with data. It could be that you have to put both tool
sets, both tools in their tool belt. All right. Jessica Corona, “How did you get your claims
data from CMS?” Well, there’s a whole process. We pay for that data for one thing friend. You can subscribe to it and pay for it on
annual basis. Of course, there’s open data sets that CMS
allows when we bring that in too. There’s a whole subscription-based process
that we belong to that allows us to pull that data and keep it updated. Again, happy if you need to more about that. I’m happy to put you in touch with our team
that maintains that content. Robert asks, “Why does too much late binding
cause problems?” Well, as I mentioned Robert, what it doesn’t
tend to encourage is reuse of data and objects. If you go back to the litmus test that I apply
to deciding when to bind data and lock it down in a data structure, ask yourself, have
we achieve comprehensive and persistent agreement about the data logic in question. I’ll give a great example. We still debate in the industry about the
definition of hypertension. There are multiple definitions of a diabetic
patient. You need to decide which of those definitions
typically driven by a reimbursement model that you have to adhere to. Financially, you’ve got to follow CMS or you
got to follow the Blue Cross definition of a hypertensive or diabetic patient. Rather than taking late binding approach to
that and saying, “Well, we’re just going to bind that when the analytic use case calls
for it.” Go ahead and bind that upfront according to
that definition. Publish that through the tool we call population
builder. Then, you got to place to govern it and evolve
it, and also use measures manager to help manage the progression and manage the evolution
of those definitions. Late binding if applied too much becomes a
lazy person’s approach to just binding data at the last minute, when you need it. You don’t have to do any forethought or planning. That does not encourage consistency of analytics. It creates all sorts of data governance problems. The other thing that it encourages because
you’re not reusing any of those data objects is it creates performance problems and manager
problems in your platform at the technical level. Just be careful about over applying late binding. When you can find relatively comprehensive
and persistent agreement about data bindings and logic, go ahead and lock those down and
follow a more early binding approach to those rather than late binding and recreating the
wheel all the time. Okay, how will EHR and blockchain integrated
in the future? Darryl’s asking. Well, I don’t know friend. I think blockchain is over sold right now. I’m the first to jump on good ideas. Block chain is very cool but it has all sorts
of performance problems right now. The fact that’s inherently built not be private
has some security implications in healthcare. I mean you go to think about it. Block chain is all about openness and visibility
of the ledger. When you start applying that to healthcare
privacy, I just think it has significant limitations. I still think that blockchain has the possibility
to disrupt the financial industry and all the layers of inefficiency in the financial
industries that are related to the trust environment. If you think about all the different layers
of trust that go into financial transactions and audits and all of that cottage industry. Blockchain has I think a higher probability
of disrupting the financial industry in the near term than it does the healthcare industry. I think there’s lots of challenges to healthcare
industry. How do you view DOS or are you driving DOS
to serve as the total data management solution? Or is the goal for DOS to be the best analytic
solution? Stephanie is asking. Stephanie, I want DOS to be the consistent
data platform to support the three data missions that I mentioned in the first slide, which
is I want as a CIO, now as a practicing CIO, CTO out in the healthcare organizations. If you guys were … if Health Catalyst was
selling to me and I was planning for the digital future of healthcare, I would want a single
platform that I could use for analytics, unique application development, and interoperability
and portability in exchange with transaction level data all in one platform. I’d want that platform to be able to support
the ingestion and the management of data throughout the cloud of that cartoon that I depicted
in the early slides. I want one platform the future of healthcare
that supports those three missionaries in a consistent way. Let’s see here. Let’s go to Andrew Peterson’s questions. I would appreciate some comments on the role
of FHIR in the DOS. Well, we’re doing our best to build APIs around
FHIR. The truth is … FHIR is a good framework
I must say. I support it. I think it’s wonderful. The origins of FHIR go back to rebellious
opposition to message-oriented architectures and moving to APIs is great movement. It hasn’t evolved as quickly now that the
drawback is because it’s essentially an international standard. Standards-based groups like that tend to evolve
quite slowly. That’s what we’re seeing right now is that
the progression of FHIR just not moving as quickly as we’d like to see. Then, the other side of that is that where
we can, we’re extending FHIR on our own. Acknowledging that FHIR is going to catch
up at some point. We generally want to be supportive of FHIR. It’s just not moving as quickly as it should. I want to be very frank and honest to friends. We’re not as capable with our APIs, our FHIR
APIs as I would like us to be yet. It’s just a matter of … we just been working
on other things. Part one of my themes in 2019 is the development
of the DOS developer program and we’re going to put engineering resources on API development,
which will include FHIR acceleration in 2019. Okay, let’s see here. How do you transfer … this is from Nancy
Coni. How do you transfer the data to staff caregiver
queue? Great question friends. I’ll try to remember all the different ways. We can do it through our Qlik and Tableau
applications. For example, we can drive work queue back
to the caregivers through that traditional user interface. We can inject work queues back into the EHR. We’re doing that quite a bit. In our care management suite and application
of course, that’s all about prioritized work queues and so, that’s all natively built in
to the application. In our patient safety surveillance suite,
it’s all about work queues and that’s all been implemented in a web framework, in the
web application that we can embed in EHR or do it standalone for morning rounds, afternoon
rounds, that kind of thing. There’s that answer. Peter Marks asked, “This is a big investment. Do we have to go all in? How can we start and demonstrate outcomes
to executives? Can this happen in a few months?” Yeah, we quite often engaged like that Peter. We feel very confident that we can show go
a risk and we can deploy the platforms so quickly and we can accelerate to improvement
so quickly that the value becomes pretty evident and undeniable. Yeah, we’re definitely open to that and we
enjoy that pressure. Thanks for asking. Let’s see. Stephanie asked another good question here. The healthcare data sphere is not just the
data and organization creates but the data that it can acquire. Yeah, totally agree. That’s why more and more Health Catalyst is
becoming a digital systems integrator. We’re going to get in to the data production
business and enable our clients to produce their own data where data does not exist but
it’s also the acquisition of data. I always advocate, if I were still a practicing
CIO, I’d have a strategic data acquisition plan to round out the understanding of the
patient in the cartoon that I had in the slide deck. There’s some data that we have and then, we
are producing as healthcare providers and there’s some data that we don’t have. What your acquisition strategy going to be
to get that data that you don’t have. Lay that down as a five to 10 year roadmap. I still have yet to see any healthcare organization
in the US build out as strategic data acquisition roadmap that’s as formal as any other strategic
roadmap. I still haven’t seen that. You have one other part of your question,
how readily does DOS and all of its prebuilt capabilities we see periodic third party data
and days of service? Well, we’re capable of that. I mean we’re already doing that I think Stephanie
if I understand your question. I’ll just say that we totally recognize the
need for that and I would say that we’re already doing that. Jeff Morgan ask, “When will these tools be
affordable for specialized industries like behavioral health?” Let me answer that question first Jeffrey. Yeah, affordable. Well, we address behavioral health in our
current client base. I don’t know if what you’re suggesting is
how do we sell this to specific clinics that are involved in behavioral health. If that’s your question, then it is a harder
challenge for it to be affordable. We’re pursuing that level of affordability. We may not be there yet. If you’re part of a larger organization that
has a subscription that are licensed to Health Catalyst, then we definitely support behavioral
health and we definitely … especially in our analytics accelerators, we definitely
make that possible for you. I see the second part here. I wouldn’t mind hearing more Jeffrey about
your comments here. Make sure I understand your need and what
you’re suggesting. The importance of behavioral health and addressing
those analytic needs is fundamental. It ups the risk of every patient category
in every condition. Yeah, please help me understand what you’re
asking a little better. Okay, Maxine asked, “You mentioned Health
Catalyst’s going to incorporate radiology data, are you thinking to enter the VNA market
or maybe sit on top of VNA, and do some analytics?” I don’t know yet friend. I think again what I’d like to provide is
a single platform for all of the data that’s necessary for those three missions that I
mentioned earlier. I don’t know. I haven’t thought about it much yet but what
I do know is that making imaging data easier to access and easier to analyze within the
context of the discrete data we talked about, the text data that we talked about, interoperability
and portability that we talked about. Imaging data is fundamental addition to each
of those mission areas. I don’t have a strategy well lined out for
that yet friend, so happy to learn more and talk more about that. Suzanne asks, “How do you see challenges around
sharing, and click, and PHI, and utilization of systems like DOS. Secondary usage around patient care and operations
consent and concept of data ownership. Is this taking in to consideration in the
architecture?” We’re actually working through that Suzanne. In the US in particular, it’s interesting. HIPAA for example is defined pretty rigid
standards and behaviors around security of data but privacy of data is still largely
undefined. What we find in our clients is a lot of local
definitions about data privacy. As opposed to GDPR in Europe or very specifically
privacies defined, and the consumer has a lot of data rights that are very specifically
legislative in GDPR. We haven’t seen that sort of thing happened
yet. Vermont is moving in that direction as a state. They just pass a law not too long ago that
forces data brokers to declare and register with the state. If you’re going to offer services in the state,
you have to declare that you’re data broker, and you have to declare how that data is being
used. Here’s one thing that I am strong advocate
for. Number one, we have to utilize this data. It’s almost as important as donating blood. Donating and contributing your data to the
betterment of healthcare is I think fundamentally important for all of us in the entire population. Maintaining privacy and confidentiality is
fundamental at that. I would like eventually to have a model in
which the economics, if we benefit for example, health catalyst benefits from many economic
secondary use, then I want to find a way to very tangibly return those economic benefits
back to patients and let them see how they are benefit economically or from their healthcare
improvement through the contributions that their de-identified data has played to Health
Catalyst benefit. That’s one thing we’re pursuing and investing. The other is … let me tell a quick story. I had a colleague when I was back in the air
force, National Intelligence Community, who she casually mentioned one time to a physician
that she occasionally suffered from depression. Well, this person had a top secret clearance. She didn’t have a chronic problem with depression. She casually mentioned it. It got entered into her medical record as
a problem, an ICD code. It got entered into her clinical notes. Well, when her top secret SCI clearance, which
is the highest level of top secret compartmented information. When it came out for her background investigation,
that came up in her record, and they put her clearance on hold and delayed the renewal
of that clearance because the investigators perceived depression as a security risk. I’m a giant advocate for patients taking greater
ownership of the data that’s contained in their electronic health records and things
like forgetting data and frankly, eliminating data. That has to be the future of healthcare. Does it really matter if you’re 50 years old,
and you had a sexually transmitted disease when you were in college. Should that still be in your record? Probably not. You should have the right to eliminate that. We haven’t quite figured out how to do that
yet technically but conceptually, we appreciate it. We want to be advocates for that thing in
the industry. Okay, let’s see here. Next question. For Brian. Hey, Brian. Brian Gregory. Cleaning data from spreadsheets is a big problem. Do you have an installation roadmap that tackles
that problem so that some analysis can be done before you migrate all those spreadsheets
to a cleaner data warehouse. No, the short answer to that is not really
Brian. The best way to clean up data is to expose
its ugliness in public. What we generally do to clean up data is not
take ownership of the cleansing but take ownership of the exposure of the dirt. Get everybody motivated to see the value of
cleaning up that data and the importance of cleaning it up and making good decisions. We’re improving the tools that we have to
assess data quality, and I’ll describe to you the definition that I have followed for
data quality for a long time and that is data quality equals data completeness times data
of validity. Completeness is pretty straightforward. There are lot of nulls and missing values. That’s easy to understand, easy to compute. Then, understanding why there are nulls in
healthcare is really important too. It’s not like the sensor that’s dropped telemetry
on a satellite. If a patient drops a lead because the adhesive
is irritating their chest. That’s a very different null value than a
sensor that outright fails. Or if a nurse decides not to collect a vial
because they want to wake up a patient that’s otherwise doing fine. That’s a very meaningful null value that you
want to understand. Data validity is a harder thing to manage
in healthcare and harder to understand. It can include things like cardinality checks. It include things like references against
gold standards. Those are computable. Validity is a hard thing to measure and manage
in healthcare. All I can say is we’re building out tools
to improve our data quality measurement, not data quality improvement. We fundamentally believe that you have to
clean up data at the source level not take on the responsibility of cleaning data when
you load it in the warehouse. We’re building out tools constantly that improves
the visibility of poor data quality realizing that there’s this asymptote of difficulty
in healthcare that no tool is ever going to be able to fix completely. Okay, last question friend. Friends, thanks for hanging in there. Hi Dale, you mentioned Qlik and Tableau are
expensive and best serve a smaller population of users, the drillers. Will Health Catalyst develop a standalone
data utilization tool embedded in DOS? Well, that’s what we’ve done Mark with leading
wisely. It’s not the same kind of tool and experience
that Qlik and Tableau provide. We’re not going to compete with them in that
space. They’re great tools. They’re way ahead of us. PowerBI and Microsoft strength is coming along
in that space. There’s no way we want to get into that but
leading wisely provides, I would say limited driller capability but lots of clicker capability
for the clicker personas of the world. Qlik and Tableau are frankly overkill. Yeah, we’re developing tools in analytics
that push data to the edges of the organization and address those free user personas that
I mentioned earlier and let Qlik, Tableau, PowerBI, let them occupy the space that they’re
good in. We’ll provide a cheap embedded tool set to
get data out to the other user personas in the edges of the organization. Okay, holy smokes. I’m going to stop talking. Thanks everybody. I really appreciate all the great questions
and look forward to further dialogue, anything else that we can do to help. Great. That was fantastic. An extra 27 bonus minutes there of Q&A. We want to thank Dale for taking the time
to present to us today, and we want to also thank all of you for joining us.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *