The API era: Symptoms Checker

Symptoms Checker is a bundle of components meant to ease developing applications that leverage on the [ApiMedic API](http://apimedic.com/). The bundle is composed by 3 elements: 1. **SymptomChecker

March 17, 2018

Symptoms Checker is a bundle of components meant to ease developing applications that leverage on the ApiMedic API.

The bundle is composed by 3 elements:

  1. SymptomCheckerStateless : a low level library that encapsulates the ApiMedic Web API
  2. SymptomCheckerStateful : a high level library that leverages on 1. and implements workflow state information
  3. SymptomCheckerApp : an cross-platform application infrastructure that uses 2. to deliver final user applications. The Android Flavor is published for evaluation, with a basic user manual.

The API era

We live in the API era. Our time is characterized my a massive migration from physical to virtual. Something similar to what happened in the past with the invention of telephone, cinema or television.

Information technology is changing from local to global. The internet is becoming infrastructure like the electrical and transportation networks. We move goods on roads, energy on wires, information on fibers.

What industries and warehouses are for goods or centrals are for energy, the cloud is for information.

To get goods we use shops, to get energy we plug our appliances. And, to get information we... call some APIs.

API stands for Application Programming Interface and it's not a new name. I remember using this acronym since the beginning of my interest for programming, back in the 80s.

However, the virtualization process going on in the last years has revitalized the term API. As a matter of fact, programmers have always called some API, either to access an operating system service, or to query a database. So what's new?

Well, new is that the APIs we are mostly talking about nowadays aren't generic programming interfaces, but have a specific characteristic: they involve the internet.

Businesses and institutions around the world supply information and computation over APIs, information technology companies are busy in creating and maintaining cloud infrastructures and tools, software companies make their profits by publishing fine grained front-end applications that make available that huge worth of data and powerful networking infrastructure in user-friendly-fancy formats.

To taste how this permeating glue is conquering the computer programming panorama, we just need to have a look to a website like ProgrammableWeb, a daily increasing directory of APIs in whatever field we might think of.

It is so that I discovered ApiMedic.

Technologies used in the project

I decided to use the ApiMedic Symptom Checker API as back-end for a project meant to leverage on modern software development technologies, like:

  • .NET Standard : for years .NET has been a pure Microsoft territory. It was born as sort of java competitor, but for a while it was almost confined to the Windows world. With .NET Standard and .NET Core, Microsoft is spending a welcome effort to embrace non-Windows platforms. Here we can see which platforms .NET Standard supports.
  • Xamarin.Forms : what .NET Standard and Core are doing on the back-end and Web area, Xamarin.Forms is doing with the native front-end area. The WPF/XAML technology was strictly Windows, but Xamarin.Forms make us able to write application for Android, iOS, Mac, Windows Phone and more, in a multi-platform paradigm that at the moment of writing doesn't seem to have challenging competitors.
  • F# : there are literally hundreds (if not thousands) of programming languages available nowadays, and I had studied and used several. Sometimes newborn languages really show their superiority, as if their creators did really stand on the shoulders of past language creators, while creating theirs. F# is one of them, and it has the good habit to be a .NET native.

Let's now say something more about the project elements.

SymptomCheckerStateless

SymptomCheckerStateless.DLL is a .NET Standard 2.0 library, written in F#. Stateless means that it doesn't detain any data inside it. It is a pool of functions that make easier calling the ApiMedic API.

The ApiMedic API is a REST web API with classic URL based queries. For example, to retrieve body locations the URL is

https://sandbox-healthservice.priaid.ch/body/locations?token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJlbWFpbCI6ImZyYW5jby50aXZlcm9uQGdtYWlsLmNvbSIsInJvbGUiOiJVc2VyIiwiaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvd3MvMjAwNS8wNS9pZGVudGl0eS9jbGFpbXMvc2lkIjoiMjc4NCIsImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vd3MvMjAwOC8wNi9pZGVudGl0eS9jbGFpbXMvdmVyc2lvbiI6IjIwMCIsImh0dHA6Ly9leGFtcGxlLm9yZy9jbGFpbXMvbGltaXQiOiI5OTk5OTk5OTkiLCJodHRwOi8vZXhhbXBsZS5vcmcvY2xhaW1zL21lbWJlcnNoaXAiOiJQcmVtaXVtIiwiaHR0cDovL2V4YW1wbGUub3JnL2NsYWltcy9sYW5ndWFnZSI6ImVuLWdiIiwiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS93cy8yMDA4LzA2L2lkZW50aXR5L2NsYWltcy9leHBpcmF0aW9uIjoiMjA5OS0xMi0zMSIsImh0dHA6Ly9leGFtcGxlLm9yZy9jbGFpbXMvbWVtYmVyc2hpcHN0YXJ0IjoiMjAxOC0wMi0wMyIsImlzcyI6Imh0dHBzOi8vc2FuZGJveC1hdXRoc2VydmljZS5wcmlhaWQuY2giLCJhdWQiOiJodHRwczovL2hlYWx0aHNlcnZpY2UucHJpYWlkLmNoIiwiZXhwIjoxNTIxMjc4NjcxLCJuYmYiOjE1MjEyNzE0NzF9.vhH4KJ39xv7UvflaP3Ydgr-CfmXSAHULVKvvMk4LrD0&language=en-gb

The library encapsulates the query formats and the internet connection management in the following public functional interface:

F#
let login (user:string) (password:string) (live:bool) : Access let getBodyLocations (language:Language) (access:Access) : array let getBodySublocations (location:BodyLocation) (language:Language) (access:Access) : array let getSublocationSymptoms (sublocation:BodySublocation) (birthYear:int) (gender:Gender) (language:Language) (access:Access) : array let getProposedSymptoms (symptoms:array) (birthYear:int) (gender:Gender) (language:Language) (access:Access) : array let getDiagnosis (symptoms:array) (birthYear:int) (gender:Gender) (language:Language) (access:Access) : Diagnosis let getIssueInfo (issue:DiagnosisIssue) (language:Language) (access:Access) : IssueInfo let getSpecializations (symptoms:array) (birthYear:int) (gender:Gender) (language:Language) (access:Access) : array

Being based on .NET Standard, the library can be used in developing projects for Windows, Linux, macOS, iOS and Android.

SymptomCheckerStateful

SymptomCheckerStateful.DLL is, again, a .NET Standard 2.0 library written in F#, which means that can be used in all the platform already mentioned in the stateless library. As the name implies, this library maintains status information, exposing a data model that keeps the history of queries already resolved. The names of the functions recall those in the Stateless library but what they do is substantially different:

F#
undefined

let init(storage:IStorage, culture:string) let login password let getLocations() let updateSublocations() let getSymptoms() let getProposedSymptoms() let getDiagnosis() let getIssueInfo() let getSpecializations()

The important differences are:

  • There is an additional init function with a storage and a culture parameters. This library is in fact capable of persist the data model and localize the information. Specifically:
  • If the application supplies a storage resource, the library will persist the data model as json and restore it at start-up time. This way, when the user starts the app, it will find all the data entered in a previous session, provided that the credential has not expired meanwhile.
  • The application can pass a culture name (usually the local culture), and the library will check whether the local culture is among those supported by the ApiMedic API. If so, the library will automatically query the API using that language, otherwise it will stick with English.
  • All the other functions are parameterless and returnless. This is because all the retrieved information is kept in the data model, a public instance of the following class:
F#
undefined

type Model () = member User member Password member Language member Live member FailedLogins member BodyLocations member BodyLocation member BodySublocations member BodySublocation member BirthYear member Gender member Symptoms member ProposedSymptoms member Diagnosis member SelectedIssue member IssueInfo member Specializations


 

the benefit of the Stateful library is that it relieves the application from the necessity of keeping the values coming from the API in variables; it just needs to call the functions in the correct sequence and present the Model as desired.

## **SymptomCheckerApp**

As said, the two libraries, being based on .NET Standard, can be used in projects targeting many different platforms.

  * Full fledged Windows .NET Framework applications
  * .NET Core applications running on Linux and MacOS
  * Smartdevice applications for all the major categories: iOS, Android, Windows Phone



SymptomCheckerApp is a Xamarin.Forms MVVM .Net Standard app. The ViewModel class fully encapsulates the Stateful Model and provides the MVVM plumbling required for data binding.

The beauty of Xamarin.Forms is that it abstracts devices. Most of the code is built for a non-specific device and then automatically translated to specific platform native code at compile time. No need to develop separated applications, learn completely different programming languages, familiarize with different tooling. A brilliant idea that I hope will be pursued further to implement more and more features.

For those that wish to taste it, I published the [Android flavor](https://play.google.com/store/apps/details?id=com.francotiveron.SymptomsChecker) and the [manual](https://francotiveron.wordpress.com/2018/03/17/symptoms-checker-android-manual/). [![google-play-badge](https://francotiveron.wordpress.com/wp-content/uploads/2018/03/google-play-badge.png)](https://play.google.com/store/apps/details?id=com.francotiveron.SymptomsChecker)

## **Further Development**

This project is a good base for a potential commercial product. Anyone interested is warmly invited to contact me.