Understanding the Patient List

Now let’s take a look at what is happening under the hood. Understanding the API calls the app makes will help you debug any issues and extend app functionality.

Publish the app

Publish the app on Lovable so you can open it in a browser tab and inspect the network requests.

Open the browser’s developer tools. On most browsers you can do this by pressing F12, or Cmd + Option + I on Mac.

Go to the Network tab, and filter by Fetch/XHR. This filters out everything except API calls, so you can focus on the requests the app is making to the FHIR server.

Each row in the network tab shows:

the HTTP method and URL
the response status code
the request body, if any
the response body

Keep this tab open while we go through the app.

Loading the patient list

Refresh the page. You’ll see a GET request appear in the network tab.

The URL should look like:

GET /Patient

This means we’re hitting the Patient endpoint. In the Response, you will see a FHIR Bundle. Find the entry array, each item in the array is a Patient resource.

The app reads through each entry, pulls out the name, gender, and date of birth, and displays them in the table.

Creating a patient

Fill in the create form and submit it. A new request should appear in the network tab.

POST /Patient

Click the Payload or Request tab to see the request body. It’ll be a valid FHIR R4 Patient resource.

{
  "resourceType": "Patient",
  "name": [{ "given": ["John"], "family": "Smith" }],
  "gender": "male",
  "birthDate": "1990-01-15"
}

Now look at the Response. The server returns a 201 Created response, and the same Patient resource back, but now it has an id field that the server assigned. This is the ID the app will use for any future GET, PUT, or DELETE on this patient.

After this, there is another GET to refresh the list.

Loading a patient for editing

When you click the Edit button on any patient, a new request will appear.

GET /Patient/[id]

The response is the full Patient resource for that patient. The app uses this response to pre-fill the form fields: name, gender, and date of birth.

Updating a patient

Change a detail in the edit form and save. You’ll see a new request.

PUT /Patient/[id]

The request body is the updated Patient resource. Notice that the id field is included in the request body and the URL.

In the response, the server returns 200 OK and the updated resource. The versionId field would have a new version number, confirming that the update went through. In FHIR, each update creates a new version of the resource.

Searching by name

Type something into the search box. Look for a request that appears as you type:

GET /Patient?name=[search term]

The search term is added as a query parameter in the URL. The FHIR server handles the partial matching and returns a Bundle of matching patients. This is the same search parameter we explored in detail in the FHIR Fundamentals course.

Next, we’ll build the patient detail page.