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 achieving this interoperability. 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 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.
Virtual health data tables can help you build low-code/no-code solutions that extend beyond common Dataverse boundaries, while users continue to interact with the virtual data as if it were regular Dataverse record. They allow you to be selective about data storage 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 Dataverse virtual tables (entities) solution and layer it on top of a data routing concept.
A key limitation with Dataverse virtual tables is the lack of tools to convert an existing physical table to a virtual one and vice versa, which leads to the creation of 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, you encounter 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, you can enable Encounters as virtual while configuring Allergy Sensitivity to Dataverse. You can change this configuration anytime and the custom provider immediately redirects from where the data is accessed.
Note
While the configuration changes are immediate, you're responsible for any data cleanup or move. For example, if Encounter is changed from Dataverse to virtual, the encounter records aren't automatically deleted from Dataverse.
As you virtualize more FHIR resources and their virtual Dataverse tables, each new entry also inherits 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 only one level.
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 still return data.
Notifications and exceptions: Notifications are provided in context of virtual health data tables when configured as virtual. You receive a notification 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. |
Note
The following tables and their respective expansion tables aren't actively integrated into the solution like the other 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 indicates if the patient is currently taking, has taken in the past, or will take 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, with their functions 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 lists key implementation considerations to remember if you plan to enable the virtual health data tables feature. However, this list isn't exhaustive.
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 the legacy Dataverse versions of the virtual health data tables. The virtual versions of these tables are, for example, named Encounters or Observations. Communicate changes to users. Along with system views, you 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. You can no longer have charts in personal views and dashboards if you created them 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 previously used physical Dataverse tables would no longer be available when you virtualize those tables. | 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 business. |
| Virtual tables feature a simplified security model as only organization-level security is currently supported. | Examine the security 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 works 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 deploy 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, the feature only supports a single level of link entity.
For search and filtering, the feature only supports a single level of expand entities.
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 persisting 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 need 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 only trigger on virtual tables mapped to root-level FHIR resources, and not on expansion tables.
- For data routes set to Dataverse, events only trigger 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.