Overview of virtual health data tables
The data landscape for healthcare can be complex and expensive, which creates challenges for customers and partners looking to develop healthcare solutions. Dataverse offers a powerful solution for building low-code, no-code healthcare applications, but its underlying data storage sometimes can't be the best choice for achieving enterprise interoperability.
Virtual health data tables in Microsoft Cloud for Healthcare provide an option for these customers and partners. Dataverse includes the Virtual tables feature that enables surfacing records within Dataverse from external sources. Virtual health data tables extend this feature via a custom virtual table provider for FHIR-based data. This custom provider includes more capabilities that allow you to dynamically switch the data source between FHIR endpoints and Dataverse via Data routes. For example, you can configure your solution to access Encounter data persisted on Azure Health Data Services while maintaining Allergy information in Dataverse.
Virtual health data tables can help you build low-code, no-code solutions that extend beyond common boundaries inherent in Dataverse, while users continue to interact with the virtual data as if it's just another Dataverse record. They allow being selective about where the data persists and reduce the complexity of dealing with FHIR data interchange. This solution also uses the existing entity and attribute maps used by the Dataverse healthcare APIs. It supports Application Lifecycle Management (ALM) through solution deployment and reduces the cost of ownership for system administrators.
Data routes
Virtual health data tables take the best of the Microsoft Dataverse virtual tables (entities) solution and layer it on top of a data routing concept.
A key limitation with Dataverse virtual tables today is the lack of tooling to convert an existing physical table to a virtual one and vice versa, which causes the creation of net new tables. If you need to switch to either virtual or physical, you must reconfigure your Dataverse applications to use the new table structure. Furthermore, you might have to preserve both virtual and physical tables to accommodate complex interoperability requirements. If your design approach includes both virtual and physical tables, users are confronted with two possible tables to use when creating saved views and advanced finds.
Virtual health data tables solve these challenges by allowing you to establish data routes for your tables or entities.
Note
Unsure about Entity versus Table? Go to Developers: Understand terminology in Microsoft Dataverse.
Standard Dataverse virtual tables require static mapping to the remote schema and a single data source at runtime. Data routes in virtual health data tables provide a configurable option to route requests on virtual tables to either the physical Dataverse store or to the remote FHIR endpoint. This option provides the flexibility to start with your data in Dataverse and enable connectivity to a FHIR endpoint later.
Each virtualized FHIR resource has its own data route configuration entry, so you can also route requests independently. For example, Encounters might be enabled as virtual while Allergy Sensitivity can be configured to Dataverse. You can change this configuration anytime and the custom provider will immediately redirect from where the data is accessed.
Note
While the configuration changes are immediate, you'll be responsible for any data cleanup or move. For example, if Encounter is changed from Dataverse to virtual, the encounter records won't be automatically deleted from Dataverse.
As you virtualize more FHIR resources and their virtual Dataverse tables, each new entry would also inherit this data route capability. For more information on how to configure the data routes, go to Configure virtual health data tables.
Entity and attribute maps
Virtual health data tables use the same entity maps and attribute maps used by the Dataverse healthcare APIs. You only need to map your FHIR data elements once and can rely on consistency when FHIR messages are processed.
For more information, go to Entity maps and Attribute maps.
Supported features
The following section lists the features supported by the virtual health data tables:
Create, update, and delete operations: Create, Update, and Delete operations are available on both root level and expansion resource records. You can perform these operations using the standard Dataverse forms for the virtual health data tables.
Similar to standard virtual tables, security roles determine which operation is permitted. You can restrict the create, update, or delete operations on one or more tables. Also, you need attribute maps with the FHIR Required Attribute field when you save the record to ensure conformance with the HL7 FHIR specification.
Expand: The feature supports expand tables for each available virtualized table.
Retrieve multiple query: When expand tables are configured to route data from a virtual data provider, the retrieve multiple query is supported only if the query contains filters on the parent link attribute. For example, Observation Component is an expand entity of the Observation entity. The entity map for Observation Component is configured as shown in the following screenshot:
The retrieve multiple query for the observation component must contain a filter on specific IDs of the parent link attribute msemr_observation.
Retrieve: Because the expand entries don't have a unique ID in FHIR, we don't support retrieving expand entries using an ID. The ID that appears when you select a record from a set of retrieve multiple results is temporary.
Filtering: The feature supports column filtering as defined by the HL7 FHIR specification. You can filter on linked entities for one level only.
Composite filtering: The feature supports limited composite filters for single table composite filters. For more information about composite filters, go to Composite Search Parameters in the HL7 FHIR documentation.
The feature supports the following composite filter definitions:
Composite filter Description code-value-concept Code and coded value parameter pair code-value-date Code and date/time value parameter pair code-value-quantity Code and quantity value parameter pair code-value-string Code and string value parameter pair combo-code-value-concept Code and coded value parameter pair, including in components combo-code-value-quantity Code and quantity value parameter pair, including in components Linked entities: The feature supports linked entities filters using chained filtering as defined by the HL7 FHIR specification. The level of support depends on the Azure API for FHIR version. Unsupported filter conditions surface exceptions and return no results.
Sorting: Sorting is implemented as defined by the HL7 FHIR specification. The level of support depends on the Azure API for FHIR version. Unsupported sorting conditions would still return data.
Notifications and exceptions: Notifications are provided in context of virtual health data tables when configured as virtual. Users are notified that the virtual records are available with limited sorting, and filtering is based on the Azure API for FHIR version.
Virtualized tables
The following section lists the supporting records or tables for virtual health data tables:
| Table name | Schema name | Root level resource | Description |
|---|---|---|---|
| Allergy/Sensitivity | msemr_ve_allergyintolerance | Yes | Risk of harmful or undesirable, physiological response that is unique to an individual and associated with exposure to a substance. |
| Allergy/Sensitivity Category | msemr_ve_AllergyIntoleranceCategory | No | Expand table from Allergy/Sensitivity to capture Allergy/Sensitivity Category fields. |
| Allergy/Sensitivity Reaction | msemr_ve_AllergyIntoleranceReaction | No | Expand table capturing one or more Allergy/Sensitivity Reaction values. Allergy/Sensitivity reactions are adverse reaction events linked to exposure to substance. |
| Allergy/Sensitivity Reaction Manifestation | msemr_ve_AllergyIntoleranceReactionManifestation | No | Expand table linking one or more codeable concept values to the manifestation values. These values are clinical symptoms or signs associated with the event. |
| Appointment (EMR)* | msemr_ve_appointmentemr | Yes | A booking of a healthcare event among patients, practitioners, related persons, and/or devices for a specific date or time. This booking might result in one or more encounters. |
| Appointment (EMR) Indication* | msemr_ve_appointmentemrindication | No | Purpose for scheduling an appointment, as specified using information from another entity. The indication is typically a condition or a procedure. |
| Appointment (EMR) Reason* | msemr_ve_appointmentemrreason | No | Reason why an appointment is being scheduled. This value is more clinical than administrative. |
| Appointment (EMR) Referral Request* | msemr_ve_appointmentemrreferralrequest | No | Referral request that an appointment is allocated to assess (incoming referral). |
| Appointment (EMR) Requested Period* | msemr_ve_appointmentemrrequestedperiod | No | Preferred time intervals for scheduling an appointment, including potential date and time ranges. |
| Appointment (EMR) Service Type* | msemr_ve_appointmentemrservicetype | No | Specific service that is to be performed during an appointment. |
| Appointment (EMR) Slot* | msemr_ve_appointmentemrslot | No | Slots from participants' schedules that the appointments fill. |
| Appointment (EMR) Specialty* | msemr_ve_appointmentemrspecialty | No | Specialty of a practitioner required to perform a service requested in an appointment. |
| Appointment (EMR) Supporting Information* | msemr_ve_appointmentemrsupportinginformation | No | Additional information to support an appointment. |
| Condition | msemr_ve_condition | Yes | A clinical condition, problem, diagnosis, or other event, situation, issue, or clinical concept that rises to a level of concern. |
| Condition Body Site | msemr_ve_conditionbodysite | No | Anatomical location where a condition manifests itself. |
| Condition Category | msemr_ve_conditioncategory | No | Category assigned to a condition. |
| Condition Evidence | msemr_ve_conditionevidence | No | Supporting evidence or manifestations based on which a condition is suspected or confirmed. |
| Condition Evidence Code | msemr_ve_conditionevidencecode | No | Manifestation or symptom that led to the recording of a condition. |
| Condition Evidence Detail | msemr_ve_conditionevidencedetail | No | Links to other relevant information, including pathology reports. |
| Condition Stage | msemr_ve_conditionstage | No | Clinical stage or grade of a condition. The value can also include formal severity assessments. |
| Condition Stage Assessment | msemr_ve_conditionstageassessment | No | Reference to a formal record of the evidence on which a staging assessment is based. |
| Encounter | msemr_ve_encounter | Yes | An interaction between a patient and healthcare providers for providing healthcare services or assessing the health status of a patient. |
| Encounter Account | msemr_ve_encounteraccount | No | The set of accounts used for billing for an encounter. |
| Encounter Class History | msemr_ve_encounterclasshistory | No | The class history permits the tracking of encounter transitions without needing to go through the entity history. |
| Encounter Diagnosis | msemr_ve_encounterdiagnosis | No | List of diagnosis relevant to an encounter. |
| Encounter Episode Of Care | msemr_ve_encounterepisodeofcare | No | Episodes of care that an encounter should be recorded against. |
| Encounter Hospitalization Arrangement | msemr_ve_encounterhospitalizationarrangement | No | Any special requests made for a hospitalization encounter, such as providing specific equipment or other things. |
| Encounter Hospitalization Courtesy | msemr_ve_encounterhospitalizationcourtesy | No | Special courtesies (such as VIP and board member). |
| Encounter Hospitalization Diet | msemr_ve_encounterhospitalizationdiet | No | Used to track a patient's diet restrictions and preferences. |
| Encounter Location | msemr_ve_encounterlocation | No | List of locations visited by a patient during an encounter. |
| Encounter Participant | msemr_ve_encounterparticipant | No | List of people responsible for providing a service. |
| Encounter Participant Type | msemr_ve_encounterparticipanttype | No | Indicates how an individual participates in an encounter. |
| Encounter Reason | msemr_ve_encounterreason | No | Reason an encounter takes place, expressed as a code. For admissions, this value can be used for a coded admission diagnosis. |
| Encounter Status History | msemr_ve_encounterstatushistory | No | Permits the encounter entity to contain the status history without needing to read through the historical versions of the entity, or even have the server store them. |
| Encounter Type | msemr_ve_encountertype | No | Indicates the specific type of encounter such as email consultation, surgical day-care, skilled nursing, and rehabilitation. |
| Episode of Care | msemr_ve_episodeofcare | Yes | An association between a patient and an organization or healthcare providers during which encounters occur. |
| Episode Of Care Account | msemr_ve_episodeofcareaccount | No | The set of accounts used for billing for an episode of care. |
| Episode Of Care - Care Team | msemr_ve_episodeofcarecareteam | No | List of practitioners facilitating an episode of care for specific purposes. |
| Episode Of Care Diagnosis | msemr_ve_episodeofcarediagnosis | No | List of diagnosis relevant to an episode of care. |
| Episode of Care History | msemr_ve_episodeofcarehistory | No | The history of statuses that an episode of care goes through, without requiring to process the history of the resource. |
| Episode Of Care Referral Request | msemr_ve_episodeofcarereferralrequest | No | Referral requests fulfilled by an episode of care. These requests are incoming referrals. |
| Episode Of Care Type | msemr_ve_episodeofcaretype | No | Classifies the type of episode of care such as specialist referral, disease management, and type of funded care. |
| Location | msemr_ve_location | Yes | Details and position information for a physical place where services are provided, and resources and participants could be stored, found, contained, or accommodated. |
| Location End Point | msemr_ve_locationendpoint | No | Technical endpoints providing access to services operated for a location. |
| Location Hours Of Operation | msemr_ve_locationhoursofoperation | No | Indicates what day or time during a week is a location open. |
| Location Telecom | msemr_ve_locationtelecom | No | The contact details of communication devices available at a location. The value can include phone numbers, fax numbers, mobile numbers, email addresses, and web sites. |
| Location Type | msemr_ve_locationtype | No | Indicates the type of function performed at a location. |
| Medication Request | msemr_ve_medicationrequest | Yes | An order or request for both supplying the medication and the instructions for administering medication to a patient. |
| Medication Request Based On | msemr_ve_medicationrequestbasedon | No | A plan or request that is fulfilled in whole or in part by a medication request. |
| Medication Request Category | msemr_ve_medicationrequestcategory | No | Type of medication usage. |
| Medication Request Detected Issue | msemr_ve_medicationrequestdetectedissue | No | Indicates an actual or potential clinical issue with or between one or more active or proposed clinical actions for a patient. For example, drug-drug interaction, duplicate therapy, and dosage alert. |
| Medication Request Event History | msemr_ve_medicationrequesteventhistory | No | Links to provenance records for past versions of this entity. These records identify key state transitions or updates that are likely to be relevant to the user looking at the current version of the entity. |
| Medication Request Reason Code | msemr_ve_medicationrequestreasoncode | No | Reason or indication for ordering medication. |
| Medication Request Reason Reference | msemr_ve_medicationrequestreasonreference | No | Condition or observation that supports why a medication was ordered. |
| Medication Request Supporting Info | msemr_ve_medicationrequestsupportinginfo | No | Additional information (such as patient height and weight) that supports a medication order. |
| Medication Statement* | msemr_ve_medicationstatement | Yes | A record of a medication that a patient is consuming. The medication statement may indicate whether the patient is taking the medication now, or has taken the medication in the past, or will be taking the medication in the future. The source of this information can be the patient. |
| Medication Statement Based On* | msemr_ve_medicationstatementbasedon | No | Collection of related plans, proposals, or orders fulfilled in whole or in part by this event. |
| Medication Statement Derived From* | msemr_ve_medicationstatementderivedfrom | No | Allows linking the MedicationStatement to the underlying MedicationRequest. The value also allows linking to other information that supports or is used to derive the medication statement. |
| Medication Statement Part Of* | msemr_ve_medicationstatementpartof | No | Collection of related, larger events, of which this particular event is a component or step. |
| Medication Statement Reason Code* | msemr_ve_medicationstatementreasoncode | No | Collection of reasons for why the medication is being/was taken. |
| Medication Statement Reason Reference* | msemr_ve_medicationstatementreasonreference | No | Collection of conditions or observations that support why the medication is being/was taken. |
| Medication Statement Status Reason* | msemr_ve_medicationstatementstatusreason | No | Captures the reason for the current status of the medication statement. |
| Observation | msemr_ve_observation | Yes | Measurements and simple assertions made about a patient, device, or other subject. |
| Observation Based On | msemr_ve_observationbasedon | No | A plan, proposal, or order that is fulfilled in whole or in part by this event. |
| Observation Category | msemr_ve_observationcategory | No | A code that classifies the general type of observation being made. |
| Observation Component | msemr_ve_observationcomponent | No | Some observations have multiple component observations. These component observations are expressed as separate code value pairs that share the same attributes. |
| Observation Component Reference Range | msemr_ve_observationcompreferencerange | No | Guidance on how to interpret the value by comparison to a normal or recommended range. |
| Observation Interpretation | msemr_ve_observationinterpretation | No | The assessment made based on the result of an observation. |
| Observation Performer | msemr_ve_observationperformer | No | The person responsible for asserting observed values as true. |
| Observation Reference Range | msemr_ve_observationreferencerange | No | Guidance on how to interpret the value by comparison to a normal or recommended range. |
| Observation Reference Range Applies To | msemr_ve_observationreferencerangeappliesto | No | A set of codes to indicate the target population applicable to the reference range. For example, a reference range can be based on the normal population or a particular sex or race. |
| Observation Related Resource | msemr_ve_observationrelatedresource | No | A reference to another entity (which is usually another observation). The relationship type code defines the entity relationship. |
| Practitioner Role* | msemr_ve_practitionerrole | Yes | A specific set of roles, locations, specialties, or services that a practitioner may perform at an organization for a certain duration. |
| Practitioner Role Available Time* | msemr_ve_practitionerroleavailabletime | No | A collection of times when a practitioner is available or performing a role at a location. |
| Practitioner Role Code* | msemr_ve_practitionerrolecode | No | Roles that a practitioner is authorized to perform for an organization. |
| Practitioner Role Location* | msemr_ve_practitionerrolelocation | No | One or more locations at which a practitioner provides care. |
| Practitioner Role Not Available* | msemr_ve_practitionerrolenotavailable | No | Indicates the general days or periods where a practitioner isn't available or performing a role, due to a provided reason. |
| Practitioner Role Specialty* | msemr_ve_practitionerrolespecialty | No | Specific specialty of a practitioner. |
| Practitioner Role Telecom* | msemr_ve_practitionerroletelecom | No | Contact details that are specific to a role, location, or service. |
| Procedure | msemr_ve_procedure | Yes | An action performed on a patient. This action can be a physical intervention such as an operation, or a less invasive procedure such as counseling or hypnosis therapy. |
| Procedure Based On | msemr_ve_procedurebasedon | No | Reference to a resource that contains details of the request for a procedure. |
| Procedure Body Site | msemr_ve_procedurebodysite | No | Detailed and structured anatomical location information. Multiple locations are allowed (such as multiple punch biopsies of a lesion). |
| Procedure Complication | msemr_ve_procedurecomplication | No | Any complications that occurred during a procedure, or in the immediate post-performance period. |
| Procedure Complication Detail | msemr_ve_procedurecomplicationdetail | No | Details of any complications that occurred during a procedure, or in the immediate post-performance period. |
| Procedure Focal Device | msemr_ve_procedurefocaldevice | No | A device that is implanted, removed, or otherwise manipulated (such as device calibration, battery replacement, fitting a prosthesis, attaching a wound vacuum-assisted closure [VAC] device) as a focal portion of a procedure. |
| Procedure Follow Up | msemr_ve_procedurefollowup | No | Any specific follow-up that a procedure requires (such as removal of sutures). The follow-up can also be represented as a simple note. |
| Procedure Part Of | msemr_ve_procedurepartof | No | A larger event of which a particular procedure is a component or step. |
| Procedure Performer | msemr_ve_procedureperformer | No | Limited to real people performing a procedure, rather than equipment. |
| Procedure Reason | msemr_ve_procedurereason | No | The coded reason why a procedure was performed. The value can be a coded entity of some type, or can be present as text. |
| Procedure Reason Reference | msemr_ve_procedurereasonreference | No | The condition why a procedure was performed. |
| Procedure Used Code | msemr_ve_procedureusedcode | No | Identifies coded items used as part of a procedure. |
| Procedure Used Reference | msemr_ve_procedureusedreference | No | Identifies medications, devices, and any other substance used as part of a procedure. |
| Specimen* | msemr_ve_specimen | Yes | A sample to be used for analysis. |
| Specimen Condition* | msemr_ve_specimencondition | No | A mode that describes the nature of a specimen. |
| Specimen Container* | msemr_ve_specimencontainer | No | The container holding a specimen. Recursive nature of containers, such as blood in a tube in a tray in a rack, isn't addressed here. |
| Specimen Parent* | msemr_ve_SpecimenParent | No | Reference to a parent (source) specimen, which is used when the specimen was either derived from or was a component of another specimen. |
| Specimen Processing* | msemr_ve_SpecimenProcessing | No | Details concerning the processing steps for a specimen. |
| Specimen Processing Additive* | msemr_ve_specimenprocessingadditive | No | Material used in a specimen processing step. |
| Specimen Request* | msemr_ve_SpecimenRequest | No | Details concerning a test or procedure request that requires a specimen to be collected. |
Note
Appointment (EMR), Medication Statement, Practitioner Role, Specimen, and their respective expansion tables aren't actively integrated into the solution like the rest of the virtualized tables. However, you can still build your own model driven apps or update existing application templates to utilize these tables.
Things to remember
The following section has some key implementation considerations to remember when you plan to enable the virtual health data tables feature. However, this section isn't an exhaustive list.
For more information, go to Limitations of virtual tables.
| Risk | User experience | Potential mitigation tactics |
|---|---|---|
| Virtual tables don't support existing saved views and dashboards | All the charts and dashboards created using physical entities that are later virtualized would no longer function. | Refactor saved views and dashboards to use the new virtualized entity. Note the new Native text added to the front of legacy Dataverse versions of the virtual health data tables. The virtual version of these tables will, for example, be named Encounters or Observations. Communicate changes to users. In addition to system views, users also need to refactor personal views. |
| Virtual tables don't support standard charts | The charts don't function or aren't available for creation. | You need Power BI or an alternative solution for visualizing this data. Model-driven charts don't render for virtualized data. Communicate changes to users. Users can no longer have charts in personal views and dashboards if they're created before using physical entities. |
| Relevance search isn't supported | Relevance search doesn't function for virtual health data tables. | Communicate changes to users. Assess if you can use virtual entities in your deployment. The new default search experience in model-driven Power Apps is built upon relevance search. |
| AI Builder isn't supported | Any AI Builder insights that once leveraged physical Dataverse tables would no longer be available when those tables are virtualized. | Consider other Microsoft AI options. The data sets you're considering virtualizing in Dataverse should likely be analyzed with Azure services such as Azure Synapse Analytics to uncover opportunities in your clinic or business. |
| Virtual tables feature a simplified security model as only organization-level security is currently supported. | Security should be examined for compliance requirements. | If organization-wide security on FHIR based resources isn't a fit for your deployment, reconsider enabling the virtual health data tables feature. |
Known limitations
Because the virtual health data tables feature is based on Dataverse's existing virtual table solution, it has the same limitations as the virtual tables. Consider these limitations when you determine whether this feature would work for your needs.
The following limitations also apply to virtual health data tables:
The feature currently only supports connecting to Azure FHIR services, Azure API for FHIR, and Azure Health Data Services. Configurations for these versions are deployed as part of the baseline solution. For more information, go to What is FHIR service?
Support for search and sort depends on the version of the configured FHIR server. For more information, go to Overview of FHIR search.
For search and filtering, a single level of link entity is currently supported.
For search and filtering, a single level of expand entities is currently supported.
For virtual tables, relationships to non FHIR-based tables aren't supported.
Creating and deploying your own virtualized tables isn't currently supported.
Virtual health data table events
Dataverse virtual tables include the ability to register for asynchronous events from an external data source. Virtual health data tables in Microsoft Cloud for Healthcare extend this feature to raise events for activities performed on remote FHIR endpoints using the existing Dataverse healthcare APIs infrastructure. For example, if you create an Encounter on the FHIR server, it raises an event in Dataverse in the context of the virtual table msemr_ve_encounter. You can then register your plug-ins for create, update, or delete events raised on virtual encounters.
The virtual health data tables feature allows dynamic switching between Dataverse and virtual providers through data routes. Hence, it also raises these inbound events if you configure your data route value as Dataverse. In the previous example, this behavior means that you only need to register the plug-ins once against msemr_ve_encounter. Even if the data route changes between Virtual and Dataverse, it still invokes your plug-in.
This event capability allows you to register plug-ins against events to execute custom workflows for data not being persisted in Dataverse.
The following tables support virtual table events:
- Allergy/Sensitivity (msemr_ve_allergyintolerance)
- Encounter (msemr_ve_encounter)
- Episode of Care (msemr_ve_episodeofcare)
- Observation (msemr_ve_observation)
For more information on virtual table events and examples, see Enable Virtual Tables to support Dataverse events.
Prerequisites for virtual health data table events
The virtual health data table events feature is built on both the existing virtual health data table functionality and the Dataverse healthcare API functionality. Besides the prerequisites for virtual health data tables, the following prerequisites also apply to the events feature:
You have to configure the Dataverse healthcare APIs as they provide the entry point for virtual health data table events. The APIs process the messages that trigger events for virtual tables from the FHIR server. For more information, see Overview of Dataverse healthcare APIs.
Tables that participate in virtual events on the remote FHIR server should have their data route configuration values set to Virtual. Otherwise, the data would be ingested into Dataverse as part of the standard Dataverse healthcare API message processing.
Bundles posted to the FHIR server should include the HTTP method value request.method for each resource entry. For more information on this FHIR entry node, see Bundle resource element - Bundle.entry.request
For examples on how to register your own plug-ins for virtual health data table events, go to Use virtual health data table events.
Things to remember for virtual health data table events
- Virtual table events are asynchronous.
- Events are only triggered on virtual tables mapped to root-level FHIR resources, and not on expansion tables.
- For data routes set to Dataverse, events are only triggered for entity maps that aren't disabled.
- Attribute maps determine what values are provided in the entity available via the plug-in execution target object. If an attribute map isn't available for a FHIR resource node value, the field value isn't processed and available in the event payload.
Known limitations for virtual health data table events
The FHIR bundle for events currently only supports the HTTP method value request.method for PUT. All events sent during this phase are treated as virtual table externally created events, regardless of their actual type. In future updates, we're planning to differentiate between create and update operations.
See also
What is Microsoft Cloud for Healthcare? Overview of Data integration toolkit Configure virtual health data tables Use virtual health data tables Manage FHIR data using Data integration toolkit