How to Build a Universal EMR (Part 2)

A deep dive Architecture

Introduction

Last week we discussed the functionality of our Electronic Medical Records System and this week we are going to discuss how it works.  This may wax a little bit technical, but it will be completely worth it to understand how this EMR is different and better than its competitors.

Code Generation

The very first thing we are going to discuss is the Code Generation tool.  This enforces the herding of the cats that are developers into doing everything in a uniform and sustainable way: doing it for them.  This is something I've not seen other companies doing, though I have no idea why not.  While it does put some pressure on a senior developer or two, it is absolutely essential.  It ensures, as stated above, that all the code is uniform, and it also does half or more of the work for the developer putting us weeks, months or years down the road on the first day of development.  This tool relies on a solid understanding of the business processes and that a database is built that supports those processes.  All of the things detailed in this paper are mostly generated by this tool, with the exception of the database structure (schema) itself.

General Architecture

Architecture is the detail of what code runs, where it runs, and why it was put there.  This is critical for larger applications like this so we can separate concerns between User Interface (UI), Business Logic Layer (BLL), Repository Layer and Database. Generally, we don’t want any logic, besides data validation, in the UI or the database.  You do want business logic in the business logic layer, along with transformation logic making your application database agnostic.  Let’s take a look at what these layers do and how they are written.

User Interface (UI)

This is not generated by the generation tool.  This is as much art as science.  This is what we see and interact with.   For all intents and purposes, it IS the application, though this is like calling the paint and curtains the house.  Under the current paradigm, this is all designed and built in Microsoft’s Blazor technology.  Blazor uses a technique called Web Assembly (WASM) to (mostly) usurp the functionality of JavaScript and run real, type safe, modern, compiled object oriented code in the browser.  I’m not sure why, but basically nobody is using the superior development technique that largely replaces ancient, slow JavaScript. Currently the only people I can find using WASM are Figma, Lichess, Unity and Google Earth.  The one you HAVE heard of is actually a beta version.  We aren’t going to discuss UI design, as that is more art than science.  Suffice it to say that most of our development will be functional.

Application Programming Interface (API)

This consists of the four projects listed below. All are written in C#, currently in the latest version: .NET 8.

API Project

This is where the controllers that actually contain the methods the UI calls are kept.  It is basically a broker for the other three projects in this layer.

Business Logic Layer (BLL)

This is where a lot of the fun happens.  Mostly it is used as an isolation layer between the database and the UI so that a database can be swapped out and code written to translate from the old schema to the new without changing anything else.  For example, if your old database had ‘Gender’ column and your new database has a ‘Sex’ column, you could translate those values here.  Additionally, real business logic goes here.  If you need to check to see if a patient is over 50 before you schedule his colonoscopy, you do that here.  Now, the way we have things set up, we use a rules engine, where we pass in the age (well, the birthdate really) and the policy, and the engine returns a true or false, that check is initiated here.  More on the Rules Engine later.

Repository Layer

This is where all things database (except the database oddly) reside.  All the procedural code (that is not set based, or database code) to access the database resides. We use a third party package, Dapper, to make database calls and return data.  Years ago we had our own home grown Object relational Mapper (ORM) and the world caught up to us and surpassed us.  The surpassing is manifest in the form of Dapper.  Most of the code we write therefore is to package and automate Dapper.

Core Project

This is where we keep all the Data Transfer Objects (DTOs) and Application Programming Interface (API) models that we create from the DTOs.  We do that in the Business Logic Layer as detailed above.  Also, we include all the interfaces.  These are contracts for things that can’t change. It would be embarrassing if we had a client using our code that then changed and broke their application.  So, interfaces.

Database

All, or all the relational databases, are in SQL Server, currently in version 2022.  All of the data is encrypted at rest, meaning that a hacker can’t steal the file and get anything useful.  The tables themselves are locked to anyone who doesn't have administrative access, and all access to the data is handled in stored procedures.  Since we have an abstraction layer in the stored procedures we can enforce our security and multitenancy protocol there.  

Database Security

When a user (doctor or patient) logs in, they are issued a Globally Unique IDentifier (GUID, pronounced gwid) that identifies them and their session.  This GUID is stored in a JavaScript (yes I know, that is the industry standard still) Web Token (JWT pronounced jaht) and must be presented to pass every layer including the database.  The GUID is compared against the Single Sign On (SSO, more on that later) database users table and passed around to the other databases for maximum security.  The GUID must be matched to return any data at all.  This is unique in the industry and this design appears nowhere else.

Multitenancy

This means we keep everyone’s data in the same database.  The GUID detailed above is also the basis for this multitenancy.  The GUID identifies the user and the user is associated with (a) practice(s) or hospital(s) and by default can only see patients at those associated practices or hospitals.  This has many benefits:

• No local ($300MM) installations
• One pool of patients with one record each, searchable
• Robust, one installation means one maintenance team and it isn’t at the practice or hospital level
• One patient portal for all records
• One repository of truth for all things medical
• Reduced maintenance expense, and none at the practice or hospital level

Audit

There is a copy of all the tables in every database that the code generator produces that keeps changes to every record.  All updates store the old record in this schema.  All deletions are kept here as well.  We can see who changed it when it was changed and again, what the old data was.

Applications

Insurance Verification

This is our insurance verification tool that returns deductibles, copays and coinsurance from any of several clearinghouses.

Estimator

This tool is inherent in the Insurance Verification UI and adds up all the various costs and present the patient with an accurate estimate of the total cost and the patient responsibility.  This is unique in the market

Integration

This is a database of terms and values that we get from various sources and translate into our standard.

Document Management (Librarian)

This is a repository in ELK that stores documents and makes them internally searchable.  You can attach these documents to a patient encounter (we don’t use the word chart, we need a clean break from the old paradigm) or the patient’s medical record. ELK has extensions that make the contents of these documents searchable.  This is where we would keep scans of hard copies or facsimiles from lesser systems or practices.

Master Data Management (MDM)

This is the repository of all things enterprise.  This has the lists of practices and hospitals, all the various persons associated with them, insurance, addresses, phone numbers and the like, that aren’t associated with any other specific application.

Medical Record (EMR)

This is the repository of the medical records management system based on the UMLS, as discussed above.This is adequate for documenting any patient encounter, anywhere, at any time, in any of several languages.  To this we add a survey that allows the practice to ‘modify’ the EMR to ask for specific information that they deem necessary.  This is all designed and maintained by them, we just provide the functionality.  Think of it like a medical SurveyMonkey.  One of our ASCs uses this between surgery and recovery to record checks on the patient’s blood oxygen, pressure, heart rate, etc.  Further, this is the repository of all things patient education.  The Health Risk Assessment is simply a patient encounter. We can run lab results through our Health and Wellness platform and automatically prescribe either home grown patient education or documentation from our partner Krames.  It is all automatic and we can tell when the patient has read and followed the education, as evidenced by more favorable lab results, entitling the patient to discounts on health insurance.  This is all detailed in previous articles.

Messaging

This is the application that allows the user to pull various information from the databases and put it in a text message or email that is sent automatically.  These are completely customizable by the hospital or practice staff.

Practice Management (PM, pending)

This is an Enterprise Resource Management (ERP) style system that tracks and codifies every piece of equipment, every person, every building, capital assets, inventory and process into one cohesive whole.  This is designed, but has yet to be built.  There are only so many of us.

Reporting

This functionality is the one stop shop for reports.  This is what shows and prints the Estimate of patient responsibility, the singular and aggregate survey that we will discuss later, and showing the various surveys the patient fills out like pre-visit paperwork and satisfaction surveys.  More on the Survey Tool later.

Scheduler

This is the repository of all appointments.  With it we can associate any number of staff, any patient, any equipment necessary and of course a venue.  This, like everything we do, was designed to solve the general problem, and the problem we picked was Whitesnake in concert, at Reunion Arena in 1987.  That means we have a stage with the band on it, all their equipment, the venue itself, ancillary staff like bouncers and custodians, sub venues or seats, and all the people to sit in those seats.  All this is modeled with this tool making it a breeze for you to schedule appointments.

Single Sign On (SSO)

This is the holder of all things Authorization and Authentication.  This is what is used to log in the user, issue the GUID we discussed earlier, and allow them to see various application and aspects of those applications through both individual and group rights.  The schema for the database is shown in the next section.

Questionnaires (Survey)

This application details the various surveys a practice or hospital might need.  These include the individual and aggregate patient satisfaction, pre-check in, attachments of the EMR as discussed previously, and anything else the practice or hospital wants to use them for.  These are available over the internet and can be assigned to the patient, or doctor, by staff.  They are completely managed by the practice and can be configured any way the practice deems necessary.

Pre-Authorization (Pre-Auth, Pending)

This also is completely configurable by the practice or hospital and can be used to automate pre-auth.  The user opens the pre-auth tool and it shows a browser where the user can navigate to any of the various pre-auth sites.  The user can then go into administration mode and pick the input they want and associate with various information in the database, like they did with Messaging. Once they have all the inputs recorded the system remembers and fills those out for every visit to the page.  While this is fairly rudimentary, it is the best we could do while the payers are attempting to make this impossible to automate.  We do have a sample application started that shows this.

Enterprise Logging

We keep all our logging in one place: Elk Stack (Elasticsearch, Logstash and Kibana).  This makes it easy to search and find log entries and figure out what caused a problem for troubleshooting.

Rules Engine

This is a way to make our system less vulnerable to changes in logic.  For example, let’s say that we decide (together of course) that the age to start colonoscopies is 45 years old.  We can type, in text, or the doctor/practice/hospital can, age >= 45 and have it evaluated as true or false.  If the engine returns true, it is covered, if not, it isn’t.  The genius part of this is that it is all text and evaluated at runtime, on the fly not hardcoded and requiring a developer and a deployment to change.  This also allows us to have different rules for different payers.

Specific Architecture

Database

Databases are broken into entities that describe things or processes in the real world.  They are joined together by relationships that fall into one to one, one to many, or many to many categories.  Here is the schema for the SSO database as a representation of how we do things.

API

Here we see the design for the various APIs as detailed above.

BFF

Here is the broker layer that acts as an intermediary between the UI and the various APIs it needs to work.

UI

As mentioned about, this is art so there is no predesigned way to execute this process

Putting it all Together

Here we show the application specific architecture and how it all fits together and transfers information.

Conclusions

Normally we would talk about how we are saving healthcare with Patient Education and lowering premiums by over 50% and saving an additional 25% with improvements in health as a population.  Today though, is a little different.  We have taken a deep dive into the architecture and functionality of our solution to this endemic problem and shown not only a path but the execution to saving healthcare.