Channels ▼
RSS

Design

Industry-Focused Development


Jon Barcellona is principal architect for Digital Architects.

WorldDoc provides Web-based health management tools, such as personal health records, that health insurers and employers can buy for people covered under their plans. The idea is that people will use the information systems to stay healthier, thus living better and lowering costs for insurers and employers. The company's fully hosted central database engine integrates an individual's health risk assessment, medical and pharmacy claims, laboratory test results, and biometric data to provide care management such as personalized medical goals, find gaps in care, and suggest actions to stay well.

WorldDoc's vision is to build a "healthcare intervention engine" that integrates with its existing member healthcare portal. Such a system would let clinicians write rules to process health data information, medical claims, and other information for millions of members. The rules would match a person's health profile with specific interventions, which could be delivered as e-mails, text messages, Web-based coaching, mail, phone calls, and via a smartphone application. It's a highly complex vision, and it needs to execute against millions of members' health data while maintaining a high level of performance.

To do the software development, WorldDoc hired a four-person agile development team from my company, Digital Architects; it wanted a production application in one year. We had a basic development road map in mind from past experience:

  1. Clearly define the problem domain.
  2. Don't build what we could buy.
  3. Start small and rapidly deliver a proof of concept.
  4. Deliver the main project using agile principles -- especially "deliver working software early and often."

Based on our experience, we decided at the outset to create a new domain-specific language (DSL), this time for the medical domain for medical rules. A DSL is a computer programming language that targets a particular domain -- healthcare in this case -- instead of a general-purpose language such as Java or C++ that's designed to solve any kind of software problem. DSLs offer numerous benefits for projects like WorldDoc's. Users (clinicians in this case) understand them, thereby facilitating communication; they increase the productivity of software developers by raising the level of abstraction; and the system can be quickly updated if user requirements change -- a must for a project like this.

The most critical and time-consuming aspect of such a "rules engine" project was the initial analysis of the language -- understanding the healthcare domain and translating it into a simple programming language that would be intuitive to the clinicians. Another challenge was creating an intuitive user interface for clinician rule entry. Additionally, we learned that the data access layer needed to be mapped from the language elements to the WorldDoc healthcare data, so that future changes to the data structure could be changed via mapping of the language elements to the data, rather than changing the DSL itself.

Define The Problem

The project sprawled out in three big areas, according to Ben Say, World Doc's CIO. One, the clinical rules went very deep. Two, there's a huge variety of member preferences. And three, there's tremendous breadth of possible intervention the system could recommend to patients. Using a DSL let us automate more of the development.

With the DSL approach settled upon, we began defining the problem domain by categorizing the tasks at hand into problem parameters, then reorganizing those tasks into technology areas. In doing so, the problem looked like this:

Create a DSL for medical rules that:

  • Clinicians find intuitive;
  • Integrates with the existing member health data and intervention process;
  • Creates rules that execute swiftly enough to handle millions of members.

This led us to realize that we'd also need to build a Web-based portal for authoring rules that clinicians could use. It would also have to allow authoring and validation of rules syntax and data elements, as well as support fullfeatured rules testing and workflow to manage processes from the draft phase into rules production.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video