Hi, I'm Kaitlin Ryan.
Welcome to our healthcare interoperability Ask the Expert video series.
Today, Adrienne DeWitt director of product portfolio strategy, will be answering a few
questions about the TriZetto(R) interoperability data hub.
Adrienne, how did Cognizant approach to the design and development of the TriZetto(R)
interoperability data hub?
So as with the rest of our solution, for the data hub, we really one of the key components
we wanted to focus on was that ability to be flexible.
So as the data hubs been designed to take in data from any system of record where theres
interoperability qualified data, whether it be clinical, administrative, Part D formulary
drug information or provider directory information.
We wanted it to be flexible to come from any system, and then because of that we also wanted
it to be flexible and its capability of ingesting that data via various mechanisms.
So within the data hub that was one of our key components to allow as frictionless as
possible that ability to move data as required by interoperability from those systems of
record into the system where it can then be reported out through those API's as the data
hub orchestrate data.
So the data hub does data orchestration in a couple different ways.
One would be when we get a request in for data for a member, there is orchestration
involved and being able to retrieve all those different FHIR resources from our curated
data store where that data has already been transformed to FHIR and is terminology normalized.
However, the most important part of orchestration related to the data hub involves the ingestion
of data.
So as the data hub was designed to ingest data from any system of record that flexibility
was built into that and we have different ways that in which we can ingest that data,
one of which is an HTTPS API post, so that will allow if there are other systems that
you integrate with that have some of this interoperability qualified data, such as pharmacy
clinical administrative and provider directory information.
If that's being vented in an API in a fire format already that could then be orchestrated
to post that directly to our data hub.
We also support SFTP file load for batch files that may be coming in in a FHIR format from
different systems of record.
And then we also support streaming so that will allow the data as it changes in the source
system to be vented to our data hub and ingested.
And then once our data comes in through that ingestion pipeline we use an event handler
to move it through various phases.
The first one of which is that we can perform transformation into FHIR, along with the terminology
normalization for some data formats so for industry standard formats like HL7 v2 which
is an older FHIR standard, as well as for CCDA file formats like an ADT file on the
clinical side that information can be transformed into FHIR during ingestion other data that's
not going to be in one of those known industry standard formats would have to be put into
fire before it comes into the data hub, but that's step one step two would be that we
need to master that data.
So as that data is coming from all these various source systems, it's important that we can
orchestrate and aggregate the storage of that data so that we can identify for a single
member What are all those records related to them so that we can respond appropriately
to our interoperability API requests.
And then the third step of that is really performing some of that sensitivity and security
labeling and tagging on the data as it comes in.
So as data is ingested into the data hub if it comes with those security tags those will
be respected.
But as well if it doesn't have that information.
We will be tagging that information so that those security labels are there, so that as
we get into our privacy and consent engine we can interrogate those tags and make sure
that we're only sharing the information that we should.
So that's how we're going about supporting orchestration both into the data hub and out
of it.
How does the data hub master data?
So we've talked about all the different systems of record that patient data can exist in and
provider directory as well.
It's really important that as we aggregate all those records together within our data
hub that we have the ability to perform mastering on that information so EMPI which is known
as the enterprise master patient index is one of the functions that our data hub performs.
And so within that, what that means is that we have that capability to identify uniquely
a member across any of those source systems, even though they're going to have an index
of various IDs across all those other systems of record.
And so having this gives us that capability when a member asked for that information that
we can then retrieve information from various different source systems where that number
was identified uniquely in different ways across those disparate systems within the
data hub.
We also Master, any type of entity related data like that so patients organizations and
providers are mastered within the data hub.
What FHIR server does the data hub use, and why?
So within our data hub we chose to go with the HAPI FHIR server, a couple reasons for
this one was that it was capable of operating in the cloud, which is where our SaaS based
solution lives, but also it had the capability to allow us to modify some of the extensions
that exist within the HAPI FIHR server, and that allows us to support some of those implementation
guide profiles for the interoperability qualified data, as well as make sure that it's extensible
and scalable for us in the future.
Finally, what core systems, does the data hub support?
So as we designed our data hub we knew that it needed to be capable of taking in data
from any source system so that could be something from another vendor, a health plan application
or another one of our systems of record. and so that flexibility was built into the data
hub so it can support anything.
We also have tried to make that pre integration to our core admin system so data publication
that can then be streamed directly into the data hub so you can aggregate all of your
data into a single location.
Thanks Adrienne, and thanks for joining us.
You can learn more about our interoperability solutions by visiting cognizant.com/interoperability