We conclude this series of SMART On FHIR articles with Auth0 and InterSystems IRIS FHIR Repository by reviewing our application developed in Angular 16.

Let's remember what the architecture defined for our solution is like:

Our front-end application corresponds to the second column and as you can see it will be in charge of two things:

1. Redirect the login request to Auth0 and receive the response.
2. Send and receive the response of requests via REST sent to the FHIR server.

Angular

Angular is a web application framework developed in TypeScript, open source, maintained by Google, used to create and maintain single-page web applications. This "single page application" design allows us to design much more dynamic applications for the user. As we already explained in the first article, we are going to use NGINX as an application server and reverse proxy that will avoid problems derived from CORS by modifying the call headers to match that of the server.

Application design

We have designed our application with Angular Material to simulate the design of a mobile application. In our example, the application is intended to record a series of patient data such as heart rate, blood pressure and weight and for this we will send two types of FHIR resources to our server, the first will be of type Patient with which the user will register their data; The second will correspond to the Observation resource in which we will send each of the types of data that we are going to send.

The application will allow the user to see a graph with the evolution of the recorded data.

Login screen

When the user accesses the route https:\\localhost, the initial screen will be displayed from which they can request to log in.

By clicking on the login button, the application will automatically redirect the user to the Auth0 page enabled for the configured API:

After entering our username and password, Auth0 will ask us to grant permission to the application to access our data. Once access to the data is confirmed, Auth0 will redirect us to the URL that we indicated during the configuration process. Once the Access Token is generated, the Auth0 library will be responsible for including it in the header of all the calls that we launch against the server. We can see it in the following image:

Initial screen

Once logged in we will have the first communication with our FHIR server to request the information available to the logged in user, for this we will use a query by parameter sending a GET call of the following type:

https://localhost:8443/smart/fhir/r5/Patient?email=lperezra%40intersystems.com

The server response will be a Bundle type resource with the following information:

{
    "resourceType":"Bundle",
    "id":"8c5b1efd-cfdd-11ee-a06b-0242ac190002",
    "type":"searchset",
    "timestamp":"2024-02-20T10:48:14Z",
    "total":0,
    "link":[
        {
            "relation":"self",
            "url":"https://localhost:8443/smart/fhir/r5/Patient?email=lperezra%40intersystems.com"
        }
    ]
}

Como vemos tenemos un total de 0 pacientes con ese email, por lo que nuestra aplicación nos va mostrar una pantalla inicial desde la que podremos registrar nuestros datos.

As you can see we have the email field already filled in with the email of the logged in user, this is because as you have seen in the initial query, we are going to use it as an identifier. With the form filled out we will send a call of the following type via POST:

https://localhost:8443/smart/fhir/r5/Patient

With the message body formed by a Patient resource:

{
    "resourceType":"Patient",
    "birthDate":"1982-03-08",
    "gender":"male",
    "identifier":[
        {
            "type":{
                "text":"ID"
            },
            "value":"12345678A"
        }
    ],
    "name":[
        {
            "family":"PÉREZ RAMOS",
            "given":[
                "LUIS ÁNGEL"
                ]
        }
    ],
    "telecom":[
        {
            "system":"phone",
            "value":"600102030"
        },
        {
            "system":"email",
            "value":"lperezra@intersystems.com"
        }
    ]
}

With the patient data registered on our server, the patient query will now return a result, so we are now prepared to be able to record the different observations. Let's see what the initial screen looks like:

Observations screen

In the same way that we have sent the patient's data, we will send the observations from their specific screens:

For each resource sent to the server the application will add a new point to the graph:

To do this, it will launch a query to the server requesting the Observation type resources belonging to the user:

https://localhost/smart/fhir/r5/Observation?patient=Patient/1

And the server will again return a Bundle type resource with all the observations recorded for the patient:

With the result obtained, the application will extract all the numerical values and construct the relevant graphs.

Conclusion

As you have seen in this and the previous two articles, the design and creation of SMART On FHIR applications is not very complex and allows us to quickly and agilely build applications that take advantage of all the functionalities available on our FHIR server.

An application of this type will not need the development of a complex backend to manage CRUD type operations on the data and with the use of OAuth2 we will not need to manage users from the application, delegating said functionality to Auth0 or the authentication and authorization server chosen one.

With SMART On FHIR we can, in an easy and simple way, make available to patients and medical professionals the necessary tools for clinical data management.

Thank you so much for your attention!