Understanding Patient Details

Now let’s look at what API calls the patient detail page is making.

Loading the page

Refresh the patient details page with network tab open, filtered to Fetch/XHR. You will see a sequence of requests.

GET /Patient/[id]

This loads the patient demographics at the top of the page.

GET /Observation?subject=Patient/[id]&code=...&_count=500&_sort=date

This fetches all the vital signs in one request, sorted by date. All the LOINC codes are passed as comma-separated values in the code parameter.

GET /Condition?patient=[id]&_count=200

This fetches the patient’s conditions.

GET /MedicationRequest?patient=[id]&_count=200

This fetches the patient’s medications.

What the responses look like

For observations, each entry in the response bundle is an observation resource with a date and value. The app reads through these, groups them by LOINC code, and plots them on the charts.

For conditions, the app reads the code.text field containing the SNOMED CT display name and shows it in the table.

For medications, most resources have a medicationCodeableConcept field with the medication name. Some may reference a separate Medication resource instead. If a medication isn’t showing up, that might be why. Your app needs to handle both cases.

Using the network tab for debugging

If something in the app isn’t showing up as you expected, the network tab is the first place to check. See what the app is requesting, then verify in Postman that the data actually exists for that patient. If the data is there but not displaying, paste the actual resource into Lovable and prompt for a fix.

This is how you can debug a vibe-coded app. You don’t need to understand every line of code, but you do need to understand the APIs. That lets you tell the AI what’s wrong and how to fix it.

In the next module, we’ll build the same app using an IDE.