What is Backend as a Service and what does it mean in a healthcare context

The concept of a backend as a service (BaaS) is simple. All application developers (web or mobile) require a core set of features that need to be incorporated into every app. Examples of these features include user management, push notifications, integration with Facebook, Google+ etc., and cloud based data/file/image/video storage. These backend features take about 50% of overall app development time and cost.

The goal of every BaaS provider is to simplify:

• Implementation: through an SDK (software development kit) which provides a way to reduce the code required to implement all the features required to a few lines;
• Access: through a defined set of interfaces (APIs) that allow data to be easily accessed, manipulated and stored.

With a BaaS, every app developer need not code a similar or identical set of features to manage their own backend to handle user management, data storage and the like. Enabling this is a major task for BaaS platforms. It means being everything to everybody.

This has forced BaaS providers to have a broad focus and thus focus on the least common denominators - storage, user management, notifications, and social connectivity, leaving the specifics to the developer.

This is where the need for a healthcare specific backend-as-a-service surfaces.

Healthcare specific BaaS

As we built healthcare EHR Integrations and talked to other healthcare app developers and enterprises, we uncovered a core list of features that each one of us was building over and over again. Namely,

• Security: this includes identification of PHI (personally identifiable health information), encryption of PHI at rest and in transit with associated audit logs. There are some additional nuances when it comes to cloud computing and we will go into this in more detail in the subsequent blog post on cloud security.
• User Authentication & Management: this is core to any app on any environment. The nuance in the healthcare context is to handle this efficiently given the security constraints.
• Logging and auditing: Given HIPAA’s requirements to ensure appropriate access, logging and audit trails are essential for ongoing and historical compliance reporting and alerting.
• Validation: data created on the app needs to be standardized and follow terminology guidelines specified in HIPAA, HITECH, and MU2 regulations such as ICD-9, ICD-10, SNOMED, RxNORM, LOINC, and so on. This is again something we’ll spend some time on in a subsequent blog post.
• Transaction support: incoming data from EMRs, PHRs, and financial transactions follow standards as well (or will need to shortly). These include transaction sets such as EDI (X12) transaction sets (NCPDP, 5010), CCDA, HL7 3.0, and must include some legacy transaction set support for CCD, BlueButton (and BB+) and earlier HL7 versions. Additionally, transactional data in healthcare is being extended to include self-reported, ongoing wellness information (more on this in later posts about extending our view of patients). This is again worthy of a more detailed description which we will delve into in a subsequent post.
• Comprehensive Patient Model: while enforcing a standard data model is not possible nor would it be well received, allowing access to a broad list of recommended data elements (what data elements are needed to fully capture a diabetic patient’s clinical and health data?) would be welcomed. This is where we spent and are spending a lot of time to define data elements needed to capture a holistic picture of a patient. This is divided into eight categories - clinical, financial, vitals, activities, diet/nutrition, genetics, medications, and social. We will spend more time in this in a subsequent post as well.

Our mission at Datica is not just to securely support these data types and transactions but also simplify their use.

What about EHR data?

EHRs have a significant role to play in this future of healthcare. Traditionally, they have been walled off but with the evolution and implementation of accountable care organizations (ACOs) and patient centered medical homes (PCMHs), they are increasingly becoming more open. For example, Parters HealthCare providers can now view patient data collected from mobile devices on their electronic medical record platform. The traditionally complex EDI transaction set have more modern access through the likes of Eligible API and Passport Health.

The challenge with legacy EHR solutions is that they use services oriented architectures, making EHR integration with next generation apps a certain challenge for the developer trying to unlock data behind firewalls and integrating such siloed environments. Developers within and outside enterprise IT realize that rebuilding the backend and the core set of services required can cost them months of work and hundreds of thousands of dollars in costs. But everyone also realizes this needs to be done as patient engagement is the key to change. Patient engagement is elusive and the best way to engage consumers has been proven to be mobile.

Datica Managed Integration glues together these different fragmented environments. It is a unified process between the client and the cloud with unified and secure APIs and software libraries. This allows developers and enterprises to “let a thousand flowers bloom” rather than enforce just one app and technology.

The Datica mission

Our goal is to take much of the discovery and drudgery out of building a healthcare specific platform.

We accomplish this through a growing set of managed integrations and a set of SDKs (iOS, Android and Javascript) to get access to: - a health grade data store - an extensible and interoperable patient model - integrated semantic validation - health grade secure messaging - health grade user management and authentication - health grade auditing and logging - health and wellness data sources - healthcare specific test data and - health grade data archiving

Our mission is to become the defacto standard healthcare cloud platform to build, test and deploy healthcare apps.