We conducted a literature that reviewed the existing solutions in the market and where they were potentially lacklusture and how our solution would be able to fix such shortcomings
Microsoft Power Platform is a low-code development platform that allows users to create custom business applications.
It includes Power Apps, Power BI, and Power Automate. One of the main advantages of Microsoft Power Platform is
its convenience. It enables users to quickly and easily create custom solutions without the need for extensive
coding knowledge. With Power Apps, users can build custom applications for mobile and web devices. Power BI allows
users to create interactive visualizations and business intelligence reports. Power Automate enables users to
automate repetitive tasks and workflows. Power Automate is also crucial for some connectors and they give them their
true purpose. Alone, a custom connector doesn’t do much but with Power Automate, it becomes useful.
A major advantage of Microsoft Power Platform is its seamless integration with the NHS’ N365 ecosystem
[6]
Custom connectors for Power Platform allow users to connect their applications and services
to other systems and platforms. This enables users to integrate their custom solutions with other
tools and services, such as social media platforms, messaging apps, and more. With custom connectors,
users can create their own connectors or use pre-built connectors to quickly and easily integrate with
other systems.
In our case, we will be building those pre-built connectors,
allowing the user to easily consume them in a user-friendly drag and drop platform.
Currently the market standard for sending messages to people, be it WhatsApp or normal SMS’s,
is the use of Twilio. Twilio acts as a connector between the user and the WhatsApp recipient.
It is an additional layer between the sender and receiver. The advantage of this service is that
it is already in place and people don’t have to spend the time and resources to design another solution.
However, this solution is also costly.
The cost of the Twilio solution for WhatsApp is as much as $0.0647 per conversation* and an
additional $0.005 per message sent by the business (in our use case, the NHS) [18]. per WhatsApp message and large organisations
like the NHS send thousands of these messages per day. WhatsApp is free to use, but such organisations
still have to pay for Twilio. In the case of SMS’s, there is an additional cost which is the service-provider fee,
which doesn’t come in cheap. Such costs are to cover the infrastructure and services that Twilio themselves use.
Another possible solution which is very similar to Twilio is Tyntec. Tyntec is a competitor
solution but has a different payment strategy which is fixed per month at as much as €300 per month.
We are currently focusing our solution on the employees of NHS who will be on the sender side, while the patient will be the recipient.
However, this can be expanded to any corporation that should contact people using WhatsApp.
Our Solution on the other hand will be free of relevant cost for it will make use of the NHS N365 Ecosystem but beyond our E2E scenario our solution would still be more economical with any organisation using Microsoft 365.
NHS has been trying to implement newer technology like Online Consultation into the system to help improve healthcare. However, there are a lot of challenges to the current solutions for Online Consultation. For instance, sending the appointment link to the patient is a difficulty as the current solution is contacting patients by phone for scheduled appointments.[9]The NHS has a comprehensive guide for both users and patients regarding using video consultation. Online consultations are typically done through their own proprietary NHS App introduced in the COVID pandemic.[15] It required heavy verification of ID such as a passport or driving license which is difficult for older patients who are not used to technology. There are also private healthcare solutions, however they are all heavily monetised and thus are not real alternatives for our stakeholders, that being normal NHS patients who cannot attend in person.[16][17]
Our solution will provide an additional avenue for online video consultation. This will also make use of the NHS N365 license and thus making it better value for money. Additionally, some NHS trusts’ online video consultation system doesn’t link with the Patient Administration System (PAS). [10] With our connector, it would also save time on administration and ease the process by automatically adding the appointment (which is known as Telemedicine in NHS terms) and would help save staff time. The additional avenue will allow the sending and receiving of online meeting links which will be active at the time specified in the email. An email and internet connection is the minimum requirement for the NHS user to use our solution and is thus more accessible than the existing. nd if the connector is used in conjunction with our WhatsApp connector, it is also possible to send the link directly to the patient’s WhatsApp as well as email which would increase the number of communication channels when in contacting patients for scheduled appointments.
Unlike WhatsApp API or WhatsApp Business API, WhatsApp Cloud API does not require businesses to approach a WhatsApp Business Solutions Provider (BSP) to register their application to use WhatsApp API service. This removes the time and hassle of having to apply for API access through a WhatsApp BSP as well as any costs associated with them.
Webex API which is provided by Cisco and below is a summary of characteristics and functions of webex API :
Make sure you're signed in to the Developer Portal. Click the copy icon. Click OK in the dialog to copy the token to your clipboard.
The Webex APIs are RESTful. In REST, each resource is represented by a base URL like and the HTTP methods , and are used to request data and perform actions on those resources. For methods that accept request parameters the platform accepts either or content types and currently only supports returning data in format
The development environment had multiple sequential sub-environents which distinct parts of the connector were to be developed. The sections were:
This is where the connector is used. This consists of triggers, actions and conditions. The Trigger begins the flow. For our testing, we used a manual trigger, however, when under commercial deployment, the trigger can be set to anything such as an addition to a sharepoint list etc. Actions are where the flow executes what is desired such as sending the message or meeting link. Connectors are used in flows to call their actions. When using the connector in a flow, you can select the actions to be executed by the flow such as sending the meeting link or message via WhatsApp. and Templates are prebuilt flows which can be used in our own custom workflows. We will have developed our own templates to test the function of the connector.
The technologies researched above were necessary to the project and so there was little choice in choosing alternatives for each technology. To test the API, we had two choices of software, as the custom connector development environment allows us to select from a variety of imports.
Postman is a client that allows us to test API's allowing the test of HTTP requests such as POST, PUT, GET, DELETE as well as supporting of authentication, in particular, API keys (necessary for the WhatsApp API authentication) and OAuth (necessary for the WebEx API authentication). It also allows us to save requests to a collection which makes it easy to transfer a bulk of requests with other softwares . It provides us with a status code of our calls and allows comprehensive analysis of responses, in particular syntax highlighting and storage of responses to history, allowing us to analyse the progress of our API tests. Additionally, it provides a very user friendly UI allowing for fast and efficient navigation of the application. This is particularly important to us as we are not familiar with the concept of API testing, so having such a user friendly environment will help us learn and test our API's effectively. Additionally, it has collaboration tools that will allow all of us to test multiple aspects of the API faster, speeding up development.
cURL is similar to Postman in the sense that it allows us to test API's and can test additional protocols such as
IMAP, FTP and SMTP. This however is not particularly necessary as we will only be using HTTP. Furthermore all the te
sting is done primarily via command-line
and therefore is not as user friendly, which is of vital importance to us.
Our final decision was to go with Postman primarily due to the user friendliness and ease collaboration.
Our technologies we have pursued are: WhatsApp Business API, WebEx API, the Custom Connector and Flows
Development Environment and Postman for testing our APIs. The main reasons for our technical decisions
to use the WhatsApp and WebEx API are as follows:
Here is a side-by-side cost comparison for sending about 800,000 messages a day using Twilio and the WhatsApp Business Cloud API:
The benefit of online interaction between patients and their general practices
continues to grow as over a quarter of the patient population are now registered to use GP online services.[12]