As COVID vaccines began to become readily available in the early months of 2021 many healthcare organizations were rapidly mobilizing to host events to efficiently distribute these vaccinations. It was not only difficult to get events coordinated and people registered but there was also a challenge in ensuring that vaccines were equitably distributed to at risk and underserved communities in addition to those with the means and schedules which allowed them to travel long distances for vaccinations.

In the St. Louis, Missouri region a few large community healthcare providers banded together to allocate some of their allotted vaccinations with the specific intention of ensuring these vaccinations were made freely available and targeted towards some of our city’s underserved communities. As the discussions for these events were beginning our firm, ArchitectNow, was engaged to help to quickly and efficiently put in place a registration and data management solution to ensure patients could efficiently register for an open timeslot and that they could be checked in and the necessary vaccination record could be tracked and submitted to our Missouri vaccination database for the necessary reporting.

The purpose of this post is to describe the technologies utilized and the implementation of the overall platform.

Technology Selections

From the moment we were involved in this project we had about 3 weeks to completely design, implement, and launch our solution. Knowing the need for a powerful and stable solution but also one that could be delivered in such a tight timeframe we knew quickly we would not be able to custom develop a solution from scratch and would instead need to rely heavily on existing platforms and low-code solutions.

Pre-Event Sign-Up: Angular and .NET Core

The patient sign-up process was intended to a simple “fire and forget” process where a community member hits a small mobile friendly website which provides information on the events themselves. To sign-up for a vaccination, they would fill out a form with basic contact information while selecting a timeslot during one of our vaccination dates. As these timeslots (and events) fill up they would be unavailable for future registrations. Upon a successful sign-up we would be sending email notifications and reminders to individuals who provided an email and SMS/text messages to those who provided mobile numbers.

To build this mobile-friendly web experience our team leaned on a technology stack we were familiar with and leveraged a simple Angular application (written in TypeScript) that interacts with the server via an API developed on Microsoft’s .NET Core framework (written in C#). The entire solution was developed within a few days and leveraged only two ‘screens’ in Angular: a home page and a registration page.

Database: Microsoft DataVerse

As we were implementing the web-based sign-up process we had to choose a data storage platform which would simplify the remaining components of our overall solution. With the power of the .NET framework components, we knew we could read and write data from most database platforms out there. We were also aware that the timeframe for implementation was such that we didn’t want to have to custom write, test, and deploy a bunch of custom, back-end administrative tools and our goal was to use Microsoft Dynamics 365 and PowerApps. By leaning towards Dynamics 365 and PowerApps we were hoping to simplify the development of these administration tools and the necessary user interfaces which would be utilized by volunteers onsite during these events.

To put ourselves in the best (and easiest) possible scenario we decided that our solution would rely 100% on Microsoft DataVerse as its data storage platform.

After a quick design session, we realized we would only need a few entities to effectively track the data necessary for these events. These entities included:

Contact (or a patient): This entity represented an individual signing up for a vaccination. This includes basic contact information and some demographic information required for submitting data to the state of Missouri.

VaccinationEvent: This entity represented the events themselves and the configuration of our system for specific events.

EventRegistration: This entity represented a contact’s specific registration for an event. This includes the event they are registered for, the timeslot they selected, and ultimately would be the entity in which we would store information on the vaccination they received. For each vaccination we were required to track the vaccine’s lot number, arm where received, which medical professional provided the shot, and the time the vaccination was administered. The EventRegistration entity was a perfect place to store this information.

As we were initially providing doses of the Pfizer vaccine (which requires two doses) each Contact entity was also the parent to two EventRegistration entities: the first EventRegistration was for a patient’s first dose and the second EventRegistration was for their second dose.

Given the simplicity of the entity design (and the limited number of entities) we were able to complete the DataVerse setup in a few hours.

Data Administration: Microsoft Dynamics 365

To simplify management and oversight of key data (and basic reporting) we utilized Microsoft Dynamics 365 as the back-end administration tool. The security for this component was limited to a few key users for whom we purchased the appropriate licenses. We started with a new Dynamics environment set up with the Sales Professional licenses and data. This gave us a core UI and robust set of entities to start with (and also cost a bit more for the few administrator licenses we needed).

Within Dynamics, we quickly developed a model-driven PowerApps application to better represent the user experience we felt was appropriate for our use case. Within a morning we had adjusted the overall Dynamics navigation structure and added (or edited) a few model-driven screens to facilitate better management of our contacts (which we renamed Patients in the UI) and the vaccination events and registrations. We limited each data entry screen to only properties core to our business and hid all tabs and other properties.

We also updated all the necessary grid/list views for our entities to show only key columns. This not only simplified the use of the Dynamics application but also gave us quick reporting capabilities as much of the basic needs were covered by simply filtering the views within Dynamics and exporting the data to Microsoft Excel.

Within a morning we had a simplified view of all key data previously designed in DataVerse. This allowed these administrative users to log into Dynamics and have full control to add/edit/or delete any entity within our system. Since Dynamics 365 utilizes DataVerse as it’s core data source we were able to quickly have a web-based signup system (briefly described above and built with Angular/.NET Core) and a full-featured back-end administrative system (Dynamics 365) that both talked natively to DataVerse (which served as our persistence layer).

Event Management: Microsoft PowerApps

The final, and arguably most complex, requirement for the overall solution was to provide volunteers onsite with the ability to check-in patients at the appropriate time and then, when a vaccine is administered, to be able to track specific data for that patient and the vaccine they were given. This system had to be simple and efficient as the goal was to get through 1,500 vaccines per day.

To build on the already utilized DataVerse data set and to facilitate the rapid development cycle we decided on leveraging Microsoft’s PowerApps as the core platform for these features. We had secured 20 iPads to be onsite for the events and knew that PowerApps low-code capabilities and the ability to run on all devices made it a great solution for this type of targeted, line-of-business solution.

Connecting PowerApps to the entities managed in DataVerse was relatively simple but one consideration we did need to address was security. Knowing that the events we were supporting were being staffed and executed by hundreds of healthcare workers and med-students who were coming and going throughout the day we realized we couldn’t utilize named users for our PowerApps licenses. For this reason, we opted to purchase “Per-App” PowerApp licenses for each of our 20 physical iPad devices. Each device was logged in under one of these distinct user accounts and granted access to the PowerApp we developed within MS Teams.

Another design decision made during the development of the PowerApp for our vaccination events was to add all functionality to a single PowerApp instead of developing a handful of small, targeted apps for specific use cases. This was easy to accomplish, and a simple navigation system was put into place to facilitate. Users quickly became familiar with the area of the application necessary for their specific role in the event and cross-training users to move around to different areas was easy.

Outcome and Platform Agility

The entire platform described above was put together in just over 2 weeks and the initial vaccination events provided Pfizer shots to about 1,500 patients. At the conclusion of the events all relevant data was quickly and easily shared with the state of Missouri’s ShowMeVax database that tracks and reports on all vaccinations.

As the events got underway minor issues were found and major new features requirements were identified. There was no initial plan to allow for “walk-in” vaccinations as we assumed all patients would have pre-registered. It was found that we would have some surplus vaccinations and so the call was made advertise that we would be accepting walk-ins. As this new requirement was identified early on the second day of our first event, we were able to design and implement 2 new screens in just under 20 minutes within PowerApps. Within 30 minutes of the initial requirement, we had adjusted the onsite workflow and had 4 volunteers with iPads manning a walk-in desk to sign up people who hadn’t already registered using these new screens. To go from an idea to features being used in production in 30 minutes seems crazy but we were able to accomplish it easily using Microsoft PowerApps.

This strategy was such a clearly dependable solution, as we were building our solution, Microsoft release their own solution on the same Power Platform to solve the same opportunity. This  blog post describes the use case and references the  solution they created and provided for free (only charging for consumption costs) for any organization to use.

So What?

Why is this case study interesting?

It’s interesting because we completely flipped the narrative of how building software works… We rapidly created a secure , scalable , production ready solution knowing it would likely be abandoned shortly thereafter.

The highest value here wasn’t the software itself, but the tooling and expertise to create such a usable solution so quickly that it could be disposable. This takes the operational expenditure model to the extreme, but it works. Now, we aren’t saying that everyone should move to disposable software and reinvent the wheel. But we are saying that small workflows for small user bases, internal to an organization can be handled with far less complexity and upfront costs.

What could your organization accomplish by turning six figure projects into 4 figure ones? What new opportunities could be created with the additional budget? Are there legacy systems you’ve been avoiding because of the cost? Are there pain points you deal with because they are high enough on the priority list? Do you have solutions at or approaching end of life which need to be recreated?

We can talk through navigating this new frame of solutions and what it would mean to you.