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 Fast Healthcare Interoperability Resources (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.

A diagram displaying the virtual health data table flow.

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 diagram displaying the 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.


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.


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:

      A screenshot showing the observation component configuration.

      The retrieve multiple query for the observation component must contain a filter on specific IDs of the parent link attribute msemr_observation.

      A screenshot displaying sample filters for the observation component.

    • 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

This 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.
Table name Schema name Root level resource Description
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.
Table name Schema name Root level resource Description
Encounter msemr_ve_encounter Yes An interaction between patients 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.
Table name Schema name Root level resource Description
Episode of Care msemr_ve_episodeofcare Yes An association between patients and organizations 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.
Table name Schema name Root level resource Description
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 the 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.
Table name Schema name Root level resource Description
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.
Table name Schema name Root level resource Description
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.
Table name Schema name Root level resource Description
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.


The following tables and their respective expansion tables aren't actively integrated into the solution like the rest of the virtualized tables. However, you can still utilize these tables by building your own model driven apps or updating existing application templates.

Table name Schema name Root level resource Description
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 Other relevant information to support an appointment.
Table name Schema name Root level resource Description
Device msemr_ve_device Yes Identifies an instance or a type of a manufactured item that is used in the delivery of healthcare without being substantially changed through that activity.
Device Contact Point msemr_ve_devicecontactpoint No Contact details for an organization or a particular human that is responsible for the device.
Device Name msemr_ve_devicename No Represents the manufacturer's name of the device as provided by the device, from a UDI label or by a person describing the device. This value is typically used when a person provides the names or when the device represents one of the names available from the device definition.
Device Property msemr_ve_deviceproperty No The configuration settings of a device as it actually operates. For example, regulation status or time properties.
Device Property Value Code msemr_ve_devicepropertyvaluecode No Device property value as a code. For example, NTP4 (synced to Network Time Protocol).
Device Property Value Quantity msemr_ve_devicepropertyvaluequantitycode No Device property value as a quantity.
Device Safety msemr_ve_devicesafety No Provides other safety characteristics about a medical device. For example, safety characteristics for devices containing latex.
Device Specialization msemr_ve_devicespecialization No The capabilities supported on a device, the standards to which the device conforms for a particular purpose, and used for the communication.
Device Status msemr_ve_devicestatus No Status of the device availability. For example, active, inactive, entered-in-error, or unknown.
Device Version msemr_ve_deviceversion No The actual design of the device or software version running on the device.
Table name Schema name Root level resource Description
Diagnostic Report msemr_ve_diagnosticreport Yes The findings and interpretation of diagnostic tests performed on patients, groups of patients, devices, and locations, and/or specimens derived from them.
Diagnostic Report Based On msemr_ve_diagnosticreportbasedon No Indicates what was requested, such as a related care plan, medication request, or a service request.
Diagnostic Report Category msemr_ve_diagnosticreportcategory No Indicates the service category.
Diagnostic Report Conclusion Code msemr_ve_diagnosticreportconclusioncode No Codes for the clinical conclusion of test results.
Diagnostic Report Performer msemr_ve_diagnosticreportperformer No The diagnostic service that is responsible for issuing the report.
Diagnostic Report Result msemr_ve_diagnosticreportresult No Observations related to the diagnostic report.
Diagnostic Report Results Interpreter msemr_ve_diagnosticreportresultsinterpreter No The practitioner or organization that is responsible for the report's conclusions and interpretations.
Diagnostic Report Specimen msemr_ve_diagnosticreportspecimen No Details about the specimens on which this diagnostic report is based.
Table name Schema name Root level resource Description
Endpoint msemr_ve_endpoint Yes The technical details of an endpoint that can be used for electronic services. The value might include any security context information.
Endpoint Contact msemr_ve_endpointcontact No Contact details for a human to contact about the subscription. The system administrator primarily uses this value for troubleshooting.
Endpoint Header msemr_ve_endpointheader No Extra headers or information to send as part of the notification.
Endpoint Payload Mime Type msemr_ve_endpointpayloadmimetype No The mime type to send the payload in. If the mime type isn't specified, the sender could send any content.
Table name Schema name Root level resource Description
Immunization msemr_ve_immunization Yes Describes the event of a patient being administered a vaccine or a record of an immunization as reported by a patient, a clinician, or another party.
Immunization Education msemr_ve_immunizationeducation No Educational material presented to the patient (or guardian) at the time of vaccine administration.
Immunization Performer msemr_ve_immunizationperformer No Indicates who performed the immunization event.
Immunization Program Eligibility msemr_ve_immunizationprogrameligibility No Patient eligibility for a vaccination program.
Immunization Protocol Applied msemr_ve_immunizationprotocolapplied No The protocol (set of recommendations) followed by the provider who administered the dose.
Immunization Protocol Applied Target Disease msemr_ve_immunizationprotocolappliedtargetdisease No Indicates the vaccine preventable disease being targeted.
Immunization Reaction msemr_ve_immunizationreaction No Categorical data indicating that an adverse event is associated in time to an immunization.
Immunization Reason Code msemr_ve_immunizationreasoncode No Indicates why immunization occurred for a patient.
Immunization Reason Reference msemr_ve_immunizationreasonreference No Indicates why immunization occurred for a patient. The value includes a referenced condition, observation, or diagnostic report whose existence justifies the immunization.
Immunization Subpotent Reason msemr_ve_immunizationsubpotentreason No Reason why a dose is considered to be subpotent.
Table name Schema name Root level resource Description
Medication Statement msemr_ve_medicationstatement Yes A record of a medication that a patient is consuming. The medication statement could 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.
Table name Schema name Root level resource Description
Practitioner Role msemr_ve_practitionerrole Yes A specific set of roles, locations, specialties, or services that a practitioner might 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.
Table name Schema name Root level resource Description
Request Group msemr_ve_requestgroup Yes A group of related requests that can be used to capture intended activities that have inter-dependencies, such as giving medication one after the other.
Request Group Action msemr_ve_requestgroupaction No The actions (if any) produced by the evaluation of the artifact.
Request Group Action - Action msemr_ve_requestgroupactionaction No Indicates the sub actions.
Request Group Action Code msemr_ve_requestgroupactioncode No A code that provides meaning for an action or action group. For example, a section might have a LOINC (Logical Observation Identifiers Names and Codes) code for a section of a documentation template.
Request Group Action Condition msemr_ve_requestgroupactioncondition No An expression that describes the applicability criteria, or the start and stop conditions for an action.
Request Group Action Documentation msemr_ve_requestgroupactiondocument No Didactic or other informational resources associated with an action that can be provided to the CDS (clinical decision support) recipient. Information resources can include inline text commentary and links to web resources.
Request Group Action Participant msemr_ve_requestgroupactionparticipant No The participant that performs or is responsible for an action.
Request Group Action Related Action msemr_ve_requestgroupactionrelatedaction No A relationship to another action, such as "before" or "30 minutes after the start of".
Request Group Based On msemr_ve_requestgroupbasedon No A plan, proposal, or order fulfilled in whole or in part by a request.
Request Group Reason Code msemr_ve_requestgroupreasoncode No Indicates why a request group is needed.
Request Group Reason Reference msemr_ve_requestgroupreasonreference No Indicates another resource whose existence justifies a request group.
Request Group Replace msemr_ve_requestgroupreplace No Completed or terminated requests whose function is taken over by a new request.
Table name Schema name Root level resource Description
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 and 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.

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