DANA KAU:
Health, data, and FHIR at Microsoft. Previously introduced, again I'm Dana Kau in Health and Life
Sciences Cloud and Data, I'm a Senior Program Manager. I'll be presenting
the initial part of this training module. The second half of this
module will be presented by my colleague who's a
principal software engineer, Todd Morris, incredible depth of experience in the
health space at Microsoft and well beyond. We're grateful to have him co-presenting this module today. As we look at where we are
in our learning track, this is our first
module before diving into medical imaging DICOM, many other modules
ahead in the course, but just want to orient you in the linear journey
of your learnings. What do we want to cover today? We want to look at
interoperability a bit broadly and then look at Microsoft's role in history in working with health
data in the Cloud. We're going to spend some
time on the FHIR data model for those of you who are not
familiar with the FHIR spec and structure and how
that came to be adopted particularly in the US and is continuing to be adopted
around the world.
We'll look at FHIRs motions with restful APIs and we'll pave it to Todd to talk about
architectures for API for FHIR, how we've designed our
system here at Microsoft, and a specific use case as we talk about the Microsoft
Cloud for Healthcare. As we move into the next
hack over the coming days, this particular hack
is not designed to get data specifically into
the Cloud for health, but does have many,
many other use cases. We ask you to really dive
into this module and watch for the details of
how you would use our tooling to connect data
to the Cloud for healthcare, because that will not be part of our hands on experiences. For this hack, though, again, as mentioned previously, we do have other
resources available to you at Microsoft to help you get hands on keyboard as
you look to ingest data for Cloud for
healthcare use cases. As you walk out of this module, we'd love to have you
feel comfortable with how FHIR operates in REST data mode, how data is ingested
into the API for FHIR, and certainly how data egress
out of our tools work.
What is proxy OSS and some other capabilities
that we've built to wrap around the API for FHIR and enable fine grained access and other fine grained controls? How to specifically solution for a Microsoft Cloud for
healthcare use case. Interoperability,
Microsoft, and FHIR. Before we dive into
the spec itself, taking a look at why FHIR came to prominence over
the last few years, we think it's an important
pause and starting point. If we look at the way health organizations
manage data today, we see that data is
very often siloed, datasets within
individual departments, datasets and
repositories locally, and not migrated to the Cloud. The data is rarely uniform.
Data sitting in silos across
organizations requires a high friction barrier to often normalize in manual
workloads that don't involve a standard
spec like FHIR, and that work can be taxing and slow innovation in using that data for AML and
other analytics workloads. Additionally, de-identification
and non uniformity of data is difficult
and time consuming. To de-identify data without the enablement
of a spec-like FHIR is also a constraint as is the constraint
of geography. The semantics of health data, the normalization across
geographies prevents research at scale in areas
like population health. The FHIRs spec was developed, which we'll go more in
detail into momentarily by HL7 organization and
the community of open source implementers who
contributed to building out the spec to enable the
ultimate goal of health data, which is making
data interoperable.
FHIR enables interoperability by enabling a centralized
repository, particularly our products
API for FHIR enables organizations to store and organize their
data in one place, converting legacy health
data formats to formats that are used today into
one common standard, which then creates uniformity. We mentioned as we looked at the wheel of our Microsoft
Cloud for health and where we sit in that that we enable
security identification. We do that at scale so that insights can be
used for research, can be used operationally, and that BabelFish
really allows you across your organizations or the organizations that
you're supporting, should you be an ACI
to take health data in highly readable formats
and make use of that data for upstream
applications in use cases.
When we look at the history of Microsoft's role in health
data interoperability, we came into this space
really in 2019 by launching the medical imaging
server for DICOM in OSS, and we launched our Git
service of Azure API for FHIR. Microsoft in 2020 announced
the Cloud for Health, which the API for
FHIR is a part of an essential vehicle
to ingest, transform, and connect data up to
Dataverse dynamics and the other capability suites that are part of the
Cloud for health, and continuing on our
innovation journey, we launched Azure Healthcare
APIs last August. Well, I can't announce
the date today, know that around the
corner is spring, though it doesn't often
feel like that in February, but around the corner is spring, and in spring we will
be announcing moving Azure Healthcare
APIs to a GA service with lots of exciting feature functionalities around that, so really pleased to
make that movement.
We store today tens of
terabytes in the API for FHIR and we are doing
over seven billion in API cost per month
and growing rapidly. I think these numbers will look profoundly different even
over the coming months. Really if you look at this
calendar in the context in history of health data systems, context and history of
Microsoft is still nascent, but we are very
quickly building GA of highly supported services
to enable our partners. I want to move to what the differences are between the two capabilities that I've spoken about through
today's training and that's Azure Healthcare APIs and
the Azure API for FHIR, which is in GA. Moving
forward from here, we're going to specifically
focus on the API for FHIR because the API for
FHIR is a GA service. As all of you move to putting hands on keyboards
tomorrow in our hack, we want you focused on being able to use the
tooling that supports production workloads
with PHI in the Cloud, connecting from the EHR
directly to the API for FHIR.
IoT devices to our
IoT Connector, and open source capability
up to API for FHIR. As we move Azure Healthcare
APIs to becoming a GA service or GA capability
under our BA agreement will support health PHI in that environment as opposed to what we do not support
PHI in public preview, and we'll be really
excited to bring some new capabilities into
the technologies such as workspaces for security and authorization,
access management. We're going to be
bringing capability like the IoT Connector directly into Azure Healthcare
APIs product suite so that you can much more
seamlessly ingest various different
health data types into our core service and
then store that data and then connect
that data certainly out more broadly
across the stack. From here, I'm going to pivot to talking more about FHIR, its journey, and what
FHIR specifically is. FHIR is a next-gen standards and frameworks that are specifically designed to enable
interoperability. FHIR is built on
four central tenets. Number one, it's a set of
standardized data models. Those models help
normalize data, these models are often
canonical or normalized, meaning no matter where
you go in the world, a patient is a patient.
As a patient, there's a specific data
structure to patient, which we'll explore
in the coming pages. There's an API specification for exchanging
those data models, and that specification is recognized in the same
way that you would think of UL being a standards
body for power. The movement of power through
an outlet has a spec, the movement of data across
the World Wide We has a spec that's defined
by HTTP protocols. There is a very
specific API spec for exchanging FHIR data, and there's a set of
tools for building and interacting with those APIs. Many of these tools
are available on HL7's website in
the FHIR community, and that community is
really a global community of implementers who are mapping these standards and bringing
these standards to life. These standards are all about access control, they're
about regulation. We're going to specifically
call out the US as the US government was one of the first to
move forward with major legislation mandating
the use of the FHIR spec. We appreciate that this is not a US centric training and as
more jurisdictions move to adopt FHIR from both a voluntary and a
regulatory perspective, we'll certainly update
these materials and talk about those specific
jurisdictions as well.
They'll mention that
the US has a mandate , many other nations, particularly those with
centralized population pack out management initiatives and central government
health managed systems are moving to adopt FHIR today. Couple principles in FHIR. FHIR is based on web standards. It's meant to be human readable
so that you could look at whether it's an XML
file or JSON file, you could read in
human text data within the health file
and understand that data. It's structured to
be able to be easily adopted through pretty simple
set of tools and resources, which again we'll show
you some examples that are available
on HL7's website. At the highest level, many folks in the
health community really focus on the fact
that it's the implementers who are bringing this
back to life because if the spec could
be adopted easily, it wouldn't have traction and it wouldn't move to driving
health outcomes.
I see Kim has a hand raised. Kim, can I take your question? KIM:
Actually another one of our guests did and I wanted to interrupt
you for a question, so I'm just giving
him an entrance. [inaudible] do you
want to proceed? SPEAKER 1:
Hello. Thank you, Donna. In your previous slide, you talked about the Health API that is in public preview. What is the difference
between FHIR and Azure API for FHIR and other API
that you talked about? DANA KAU:
Sure, let me go back to that slide. The fundamental difference today is that the Azure API for FHIR is a generally
available service and has been for some time. Azure Healthcare APIs is
currently in public preview, meaning we do not
support putting PHI production workloads
in that environment. That service can
still be used today, but it's not used for
production health workloads. We are moving to support production health workloads
with PHI in the Cloud in the service once that service is generally available and that
date is around the corner.
In the coming days, we do be listening for an announcement from
us on moving to Azure Healthcare APIs
as GA service with capabilities to again
support IoT connectivity, not through open source tools
but native to the product. The medical imaging server for DICOM will also be
supported natively within the product and
not require using open source capabilities
to connect imaging data, IoT data, or other
data types into the Azure API for FHIR
service as a GA tool. SPEAKER 1:
So in that case Azure API for FHIR will still be there and this is a service on top
of Azure API for FHIR. Is that right? DANA KAU:
Correct. They are two different services. We will be announcing
with the release of Azure Healthcare APIs in GA more direction on the
plan for API for FHIR ahead. There are certainly
use cases where you may want to use one
service versus the other and we'll put
out some documentation around that for the GA.
SPEAKER 1:
Okay. Thank you. DANA KAU:
You're welcome. Thank you for that question.
Appreciate it. We're going to dive back
into FHIR and look at its most fundamental structure, which is a resource. You can think of a resource
as a discrete data concept. Patient will be the
primary example we use through
this course today. A patient is a
normalized resource within the HL7
FHIR organization, meaning that it's universally received and standardized
all over the world.
There are a set of
definitive data elements that are associated
with a patient, again as a discrete
data concept, and that that patient resource, second part of a FHIR definition is data that can be
moved across the web. There will be a URL associated
with that patient that URL could be called between a FHIR client and a FHIR server, and if the access
controls permit, that data can be transmitted. That fundamental definition, as we move through this course, having that grounding on a
resource is really important. Looking at a resource in
a bit more detail here, we're looking at a patient. Within the FHIR spec, a patient profile must
include the patient's name, an identifier, which we'll
cover in more detail. Identifier could be a
medical record number, for example, the
patient's gender. These are some of the data
elements that must sit within that patient's profile
to have that patient considered a full resource by the FHIR standard
and definition.
Resources, when we
look at the fact that all of these elements
are built in code, we typically work here
in JSON, and Microsoft, or XML is certainly
supported as well. Resources can be grouped together in something
called a resource bundle, a packet of
information that could include things such
as the encounter. Who was the performer
of the encounter? What is the name of
the practitioner? What is related to
that encounter? Did the patient have a procedure outside of this
particular example? Was there a diagnosis? Was medication prescribed? All of these elements can
be associated together in a bundle and that information
transmitted as required.
There's two ways that
we look at bundle. There's a transaction
bundle and there's a batch. A transaction bundle is something that
we'll be supporting in Azure Healthcare APIs. If the system fails to commit a specific resource in a bundle, then none of the resources
are committed to the file. Let's say you're trying to pull a large set of data from a
health system into FHIR, but one particular resource
element such as encounter, doesn't write to the system
in a transaction bundle, then none of the resources
will be committed. Where that is true
of batch, though, there are ways that data can be rolled back
and audited to ensure that all of the
data that was meeting to be transmitted was
done appropriately. While we've looked at a
resource individually, we've looked at
groups of resources, and now we're going
to look at another fundamental concept for FHIR, and that's something
like extension. If we look at the definition of the patient for the FHIR spec, a patient must have
three data elements, a patient must support, should an organization want to add other specific
data elements, things like the contact
of the patient, birthday, address, etc.
But some health systems,
some governments, some specific health
organizations may choose to support extensions of
resources such as nationality. If we wanted to run data
across our hospital system, we might want to
know that Mary is Canadian or Mary is
American or Mary is some specific nationality for
population health purposes. One of the architectural
principles that will cover for FHIR is that we really want to have
a structure where data is needed for 80
percent of use cases. If we look at the left
side of the page, most use cases are going to require these types of
standardized data sets, but FHIR has the
flexibility to enable extensions to be associated
with other resources, such as nationality, and
that's needed for probably 20 percent of use cases
just by specific example.
But again, this is a standard that does have flexibility to extend it be customized depending on the
implementation at hand. That's a really exciting
part of how FHIR is structured and is
able to be used. We had some base
block diagram visuals of FHIR in the prior pages, but now we're looking at
an actual screenshot of a resource here in
that resource if you look on the upper
right, it's a patient. There are some features to all resources that are standard. We're showing the
readable XTML summary here that's going to
contain common metadata, or URL where that resource
can be found with server, does this particular
patient resource live on? Here we see that the URL is calling a
structure definition.
From US course specifically, we'll talk about some
implementation guides and standards in
the coming pages, but what's the URL? Where can we find the
definition of this patient? Where can this be found? On what servers? Again, all of these data
elements are elements that are extensible beyond
what's on page here, should we want to add other
elements and associate those elements with
this specific resource. I talked a moment ago about
being able to query and find a URL on a specific resource
or resource bundle. That's the role of a server. A FHIR server is
going to be able to understand a query
from applications. It's going to be
able to validate that query should this
data be released.
Is there consent to
release and authorize the approval of this data query? Is there specific query
or specific data that needs to come back to the
FHIR server for any reason? Do we have the ability
to actually ship and send resources to the client
that's requesting that data? Not only is FHIR as
a service something that is a repository and
secure hold of data, but a FHIR server really
needs to be able to manage securely the egress and ingress of data
in and over time. A FHIR client application is
going to need the ability to request data in the query
to appropriate format, validate that data,
organize that data, and of course make meaning of
that data in applications. That's certainly the role of partners that we'd love to
see you continue to build and leverage for our client across our stack using
our FHIR server.
We talked previously
about 8020 with the example of extensibility. A big principle
in the upper left here is re-use and
composability. You want to be able to use
FHIR in a way that fits your organization and satisfies your
organization's needs. If you are a large customer with health data
repositories, again, government run
health institution, you want to be able
to ensure that the services that you're
using are scalable. Big benefit of FHIR is
transactions are stateless. Memory use is rather low in contrast to other
application types, storage types, performance
is a big part of FHIR. We want to make sure FHIR can be exchanged across networks
and the protocol is designed again with HTTP and calling you
URLs to make FHIR incredibly accessible and
usable as a spec data fidelity. FHIR does maintain a
hierarchy for lineage, you're able to trace back, puts post to the system. You're able to look at how data moved into the system
when it was written in the system and really
understand to true up any issues that
could happen with data transfers or with
patient identities.
We've historically
talked about an example where I was in theatry actually the other day for small issue, just a sprain. But if my name was
spelled with two Ns, we would want to make
sure that my name in medical record were eventually updated so that I could
be appropriately built. That my history and medical
records were accurate and the system would
track the update of associating my
incorrect spelling to my correct spelling so that that data fidelity is appropriately managed
and preserved over time.
Finally, again here,
looking at implementable, we want to be able to ensure that applications can
connect with these services, make meaning in the
use of the data, and be able to bring
that data to life. We've talked about resources. We've talked about some
examples of resources, and we'll talk about
how these resources are associated in a hierarchy
with each other. At the most fundamental level, resources are going to contain metadata, which we covered. They're going to contain some implicit rules
and a specific ID. From that resource
fundamental structure, there's a few branches. Resources will either
branch off into a bundle collection
of resources, binaries, parameters, or a
specific domain resource. A few examples we
gave previously were patient observations in many of the other
canonical resources, normalized resources
in the FHIR spec. These domain resources are going to contain specific text. They're going to
be able to point an affiliate and associate with other resource elements
when gathered together. They're never
specifically exchanged, but they are there
to inherit from the base resources themselves.
If we look at that in practice, as we move towards
some examples, you'll see here when we looked at the hierarchy
on the prior page, here is an example of a specific screenshot from
the FHIR website where we're showing a specific
normalized resource here and showing that that
resource must contain an id. Describes what an id is, what are the
constraints of that id, and something that you see on page here that's
worth calling out. You see a lot of
text that's in blue.
This text is in blue
because if you're looking to understand
FHIR in more detail, when you go to HL7's website, you can click on any of
these elements and have a very complete definition
of what is an id? When do I use an id? What is the cardinality
of that id? Is that resource
normalized or is that resource highly
used and adopted but not normalized globally across all adoptions of the FHIR spec? Again, I go back to really making sure for those of
you who are learning FHIR, getting comfortable with
FHIR for the first time, make sure to take
advantage of going to hl7.org and exploring the spec from their own words and the community of implementers who continues to develop it. How do we think about
a resource identity, defining that resource,
locating that resource? There's, again,
few branches here. We're going to look at
our resources identity from a few different ways. Location URL, where can I specifically go
find that resource? What are the identifiers
of that resource? In the same way
that I would have a medical record number or
a Social Security number, that's a way that you could
look at an identifier.
That's an element that's
uniquely ascribed and specific to me and
other definitions, like a canonical URL
that would support and help define and codify that id. We can see here is
we're going deeper into understanding what that
looks like, pen to paper. This is a patient
specific resource. You have all the elements
that are going to be included in that resource here
or can be read again, FHIR will define based on an implementation
of the FHIR spec, what must be included
and what may be included depending on
the implementation.
These are the elements that
can be explored further. This is a patient resource
is a domain resource. That's going to include how
do we define what that means? There will be a very
specific definition of what is a patient. There'll be a
specific definition of what extensions can be associated and other
defining elements associated with that patient.
Moving again here to
see that in practice. Up on the right,
you can see that the code is defining the
resource type as a patient, the specific id is scripted out and
assigned by the server. That is a big part
of the FHIR spec. That's important to
note here that the id can change from
server to server. I, as a patient, might have an identity
associated on many different servers because
I have many practitioners. But the idea for me as a
patient is going to be associated with my
specific engagement with that hospital group, and that id can change again
from server to server, depending on the full
record and identifier of what this specific resource
is going to look like. Let's go a bit more
into identifiers. There a resource that
has cardinality, which means they can have
zero or many elements. You can see identifier
defined by the arrow here in the screen
and the brackets showing that there are
very specific sets of data types that are being associated and pulled together with this identifier.
Here we're seeing terminology. Part of this
identifier is going to note what is part of
this resource type, a medical record
as part of this, what system I'm I pulling from, what specific code system
that's critical and exchanging health information between different organizations, whether those be payer,
provider or otherwise. All of this information again, within an identifier set
can continue to be expanded upon beyond the limited elements that are shown on screen here. Just going deeper into showing some of the canonical URLs that are
defined by the Firespec. We covered business identifiers
in the prior screen, as we look at some of
the canonical elements, we can look at things like a questionnaire,
a naming system. If I wanted to send a
questionnaire to a patient, there's going to be
a definitive set of information that's required to send
that questionnaire to capture information in that questionnaire
and bring it back.
The questionnaire is a very specific term in the Firespec, as is a capability statement. What is the specific
resource supposed to do, what's the purpose
of this resource? That's another canonical URL. Again, these
elements are linked, so should you want
to know more about the specific definitions of some of the URLs
shown on screen, feel welcome to go to hl7
and explore that further. How does FHIR actually
get deployed? The Firespec can be driven from implementation guides and those
guides are rules that are written by the
open-source community and those involved in specific
deployments to define how to use the resources
that are defined across the FHIR standard in deploying those
things in practice.
Again, we want to
think about how the 820 rule could be applied, what resources must be included within an
implementation, what should be included, where should extensions be used? Within defining an IG, we want to think
about constraints. Are there certain elements
we don't want to apply? Are there certain
customized operations that should be thought about? Each guide contains two
types of references. We're going to have content, what are the rules for
this implementation, how should we move forward
with this implementation, and specific use
cases demonstrating an example of how the implementation would
be deployed in theater? I mentioned that the US has
played a significant role in bringing FHIR to life from
a regulatory perspective. Back in 2016, the 21st Century Cures Act was passed in the United States, and some of the
main objectives of that Act were to ensure
that patients were able to access their
health information electronically without
cost and without friction. It took several years to develop the structures for
how the Cure Act could actually be mandated onto health organizations
in the United States, particularly those who accept Medicare and Medicaid patients, and defining how
the Act would be supported was done by the ONC's Final rule
and the CMS final rule.
We use FHIR as a part
of these rules as the standard for
interoperability of health data, meaning that patients
are going to be able to access their health
data on request, receive their health information electronically within 24 hours, and they're going to do that
by having an API connection. Again, the patient would
know about the API, but the health systems
are going to deploy that behind the scenes for the secure movement of those records to the
patient upon request. There are a litany of
additional terms moving forward today and in overtime for providers to exchange
information across each other, for payers to exchange
information across each other, for patients to be able to
access a portal where they can see what providers are available to them
within their network. Instead of having to do what we've all done for many years, call a provider, ask if
they take your insurance, ask if they take
certain coding types, so really reducing the
lift and friction for experience on the patient
was a big part of this Act.
Another big part of this Act, not to be forgotten and not necessarily stated
on screen here is that innovation in
better understanding, meaning from large sets of health data was really
part of the design in unlocking value
from health data by using standards that can
be universally adopted. Big kudos to the many, many folks involved in
passing and writing the definitions of how the Cares Act would actually
be adopted in practice. This is where we're
going to come back to implementation, guys. When you saw on the prior page, you would see in CMS's final
rulings for what would need to be made real for
patients between providers, between payers, an implementation guide
was built to say, this is how we're
going to move forward with achieving these objectives. The US Core Standard
Implementation Guide defines the parameters of
implementing for CMS and ONC, it's based on FHIR
our four standards, and provides a framework
for implementation, again as already stated there.
If you have
additional questions, particularly on regulation, we do have a great deck that we can make available to
all of you that goes into the Firespec and
regulation in detail. Profiles. Here is a
US Core reference. You're seeing a page, particularly from US Core, that's going to be part of
a main implementation guide showing the minimum constraints
required for US Core, the type of profiles use minimum elements extensions,
terminology, definitions. How do we think about
a particular hot topic in the States today, how do we think about gender, how do we represent
gender in nonbinary ways? Those are all elements that
needed to be thought about and defined in US Core, both from a structure
definition perspective, what are the official FHIR
resources we're using, what are the extensions
that we want to have considered to go beyond standard terms and canonize
resources and FHIR to support the use cases for bringing
health data to life in the US? Few more pieces here on US Core sets minimum expectations
for patient resource.
Here I'm looking at profile specifically and something
that you want to think about within an implementation guide
was we said that there's core
definitions that are to be moved forward with and
certainly constraints, and then the flexibility
of what should be supported but
doesn't necessarily have to be defined
collectively and together. Here for a patient, there's three things that a
patient must have, three definitive definitions, but elements that a
patient must support.
This is another way to
just think about FHIR, while it's a very tightly
defined structured framework, the extensibility that
FHIR offers to be able to make use of the standard
in specific jurisdictions. Now we'll look at FHIR
as a restful API. We've talked about
what resources are, how resources are defined from a jurisdictional
perspective, the role of regulation, but how does FHIR data
actually move across a system? When we think about FHIR
as a restful API turn, data is sent or retrieved from a server to a client
on an HTTP request. The path that the data flows in and some of the key
terminology to be aware of that will be used
across our hack tomorrow and across
the sessions for the [inaudible] is how do you
write data to a FHIR server.
You would want to post data, so here you see that you can create an instance
of a resource, an ID will be generated
for that resource. If you want to read data, the terminology for
that as it gets you're pulling that data
from the system to access, understand it. If you want to
update a resource, and the example that
I gave previously of a spelling error upon
admittance into an ER, you could either do
a put or a patch on that data and we do enable
the ability to delete. That's something
that we're certainly sensitive to at Microsoft. There are reasons that you would want to delete a resource, but certainly within a
core hospital system or a provider system have some
type of ongoing repository where that data is kept in and overtime for reasons of health record preservation
and otherwise, but you may not need
all elements in the exact way that they were initially ingested into FHIR, preserved for various reasons.
If we look at an actual
string here in a call to a server to get a patient and many records associated
with that patient, which is defined
here as $patient everything since a
specific period of time. You can see how
we're moving data from Contoso Hospital and Fabrikam Hospital server to call a specific patient record. Again, this is being
done with a get here we're calling a
very specific FHIR URL, we have an ID, we have the
patient everything called.
This is an example of how, you can see here in the
lower part of the screen, the patient bundle would be visualized when that
data has been called on. Here's a few other examples of RESTful interactions
with US Core, so you can see some of
the gaps and some of the combinations of how
you may want to call, particularly a patient, and you could do that through
several different ways. A combination of birthday
and name, using the ID, the patient's name,
name, and gender, and these are the exact code scripts that
could be written out to make these calls
depending on, for example, below here identifiers
such as medical record, you'd be calling a
specific hospital system, looking for that record, looking for the patient
based on that identifier.
FHIR gives you a tremendous
amount of flexibility to look for something that
you could see here is definitive of Patient
is a capital P, but do that in many ways
with the datasets that must be or may be associated
with that patient. We're going to move
here to transition to a break where a few minutes
before our split point, but I want to give everybody
a few minutes before we transition to Todd's
presentation, we'll be watching and answering
questions in the chat. Thank you for kicking
off with us and getting through the opening
description and definition of what FHIR is so that you're
very well-grounded and how we can think
about the value of FHIR in the Microsoft
data system, its value for connecting data
interoperability between health organizations
and applications with FHIR server in the middle.
When we come back from break, we're going to dive right
into more detail on our broader reference
architecture here at Microsoft and putting
together some use cases. Thanks for being with us
for this opening hour, we will reconvene at
the top of the hour in 20 minutes and go from there. Thanks again everybody, we'll
see you in a few minutes. I appreciate your time
in joining us today..
