VitalSignEquipment vs VitalSignsReadings example

Hello Zuzana Bocanski,

Greetings! Thanks for raising this question in the Q&A forum

I pulled up the actual training unit you referenced and compared it against the sample data tables shown in the "Add time series data bindings" section, and you have spotted a real inconsistency in the example, not a misunderstanding on your part.

Here is what the unit shows:

VitalSignEquipment.csv (static, lakehouse)
EquipmentId | PatientId | EquipmentType      | MonitoringStartDate
M001        | 5         | HeartRateMonitor   | 2024-01-15
M002        | 8         | OxygenMonitor      | 2024-01-16

VitalSignsReadings.csv (streaming, eventhouse)
ReadingId | EquipmentId | Timestamp           | HeartRate | OxygenSaturation
1         | M001        | 2024-01-15 08:00:01 | 72        | 98
2         | M001        | 2024-01-15 08:00:06 | 74        | 97
3         | M002        | 2024-01-15 08:00:02 | 68        | 99

You are correct that M001 is typed as a HeartRateMonitor but its readings carry an OxygenSaturation value, and M002 is typed as an OxygenMonitor but its reading carries a HeartRate value. If EquipmentType were meant to constrain which measurement columns are valid, this data would not be internally consistent.

The reason this slipped through is that the unit's actual teaching goal here is narrower than it first appears. The lesson is not trying to model realistic clinical equipment behavior, it is demonstrating the mechanics of a time series binding, specifically that the VitalSignsReadings table has one static linking column (EquipmentId) and multiple time series measurement columns (HeartRate, OxygenSaturation), and that the binding UI lets you assign each column to the correct role. The sample rows were populated to show that both measurement columns can carry values, without the author cross checking that each row's values matched the equipment's declared type. That is a content accuracy gap in the example rather than a flaw in how Fabric IQ bindings actually work.

Your instinct about a better structure is also right, and it is worth stating plainly. A schema like the one you proposed, where each reading row carries PatientId or EquipmentId plus a metric name and a metric value, commonly called an entity attribute value or narrow format, avoids this exact problem because a HeartRateMonitor would simply never emit a row with metric name OxygenSaturation in the first place. The wide format used in the example, with a fixed column per possible measurement type, only makes sense once you assume every piece of equipment can report every measurement type, which contradicts the EquipmentType field the unit also introduces.

To get this corrected in the official content, please use the Suggest a fix link at the bottom of the training unit page, since that routes directly to the content authors on the learn-pr GitHub repository.

Unit page: https://learn.microsoft.com/en-us/training/modules/create-ontology-with-fabric-iq/5-connect-ontology-to-data
Feedback link: bottom of page, "Suggest a fix?"

You can also reference the source YAML directly if you want to open an issue yourself:

https://github.com/MicrosoftDocs/learn-pr/blob/live/learn-pr/wwl-data-ai/create-ontology-with-fabric-iq/5-connect-ontology-to-data.yml

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.