Bonnie: An Open Source Clinical Quality Measure Testing Tool

Bonnie is a new open source software tool that MITRE has developed and released in April 2014 that allows Meaningful Use (MU) Clinical Quality Measure (CQM) developers to test and verify the behavior of their CQM logic.  The goal of Bonnie is to reduce the number of defects in CQMs by providing a robust and automated testing framework. Bonnie allows measure developers to independently load measures that they have constructed using the Measure Authoring Tool (MAT). Loading the measures into Bonnie converts the measures from their Extensible Markup Language (XML) eSpecifications into executable artifacts and measure metadata.

Bonnie Dashboard Page

The measure eSpecification format that Bonnie loads is Health Quality Measure Format (HQMF) XML. The HQMF specification provides the metadata and logic that describe the specifics of calculating a CQM. Bonnie can load the HQMF describing a measure and programmatically convert the HQMF specification into an executable format that allows calculating the measure directly from the specification. 

The measure metadata loaded into Bonnie is then used to allow developers to rapidly build a synthetic patient test deck for the measure using the clinical elements defined during the measure construction process. By using measure metadata as a basis for building synthetic patients, developers can rapidly and efficiently create a test deck for a measure. 

Once a CQM has been loaded into Bonnie, a user can inspect the measure logic and then build synthetic test records and set expectations on how those test records will calculate against a measure. This capability to build synthetic test patient records, set expectations against those records, and calculate the measures using those patient records provides an automated and efficient testing framework for CQMs. 

Using the Bonnie-supported CQM testing framework allows measure developers to more clearly understand the behavior of the measure logic, validate that the measure logic encodes their intent, and allows for multiple iterations of measure updates to be validated against a test deck. 

Bonnie Measure Page

Additionally, the development of a test deck as part of measure development provides benefits after the measures are finalized. The test deck build as part of measure development can be used to demonstrate the intent of the measure though the use of patient examples included in the test deck. Furthermore, the test deck provides systems that implement the measures with a means to validate the development of their systems. This is provided in the form of a base set of synthetic patient records with known expectations for calculating against the implemented measures. Finally, the test deck could be used as a basis for the test deck used as part of the Meaningful Use certification program. 

Bonnie has been designed to integrate with the nationally recognized data standards used by the Meaningful Use program for expressing CQM logic for machine-to-machine interoperability. This provides enormous value to the CQM program and federal policy leaders and stakeholders: this software tool verifies that the new and evolving standards for the Meaningful Use CQM program are tractable and can be implemented in software.   

Additionally, Bonnie was designed to provide an intuitive and easy-to-use interface based on feedback from the broader measure developer community. A key goal of the Bonnie application is to deliver a user experience that provides an efficient and intuitive method for constructing synthetic patient records for testing and validating CQMs. 

The Bonnie software is freely available via an Apache 2.0 open source license. The Meaningful Use program makes all or parts of the Bonnie software available for inspection, verification, and even reuse by other government programs or federal contractors. 

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. © Rob McCready, 2014.

Open Source Licenses for Healthcare Information Technology

Noticing that I have not been blogging as much, I want to share some perspectives on open source distribution licenses within the domain of healthcare information technology.

If well-designed, healthcare information technology solutions can improve the patient-clinician relationship, the accuracy of the patient’s health data, the diagnosis and management the patient’s health, and the efficiency and job satisfaction of clinicians.

Open source software (OSS) can play a foundational role in realizing digital healthcare delivery.  Open source software communities are intrinsically better positioned to support collaborative, community-driven demonstration of novel concepts.

Additionally, open source software lowers the barrier of entry for individuals and organizations to contribute and adopt vendor-neutral solutions in healthcare information technology.

Some of the most popular open source licenses that are used in industry are:

• Apache License 2.0 - A permissive license that provides an express grant of patent rights from contributors to users.  The Apache Software Foundation (ASF) developed the license prose, and ASF adopted the Apache License version 2.0 in January 2004.  Similar to the MIT license, the Apache 2.0 license is compatible with version 3 of the GNU General Public License (GPL) also detailed in this table. 

• GNU General Public License (GPL) v3 - A “copyleft” license that requires anyone who distributes the software source code or a derivative work to make the source available under the same terms.   Formally introduced in 2007, the Free Software Foundation (FSF) upgraded the GPL v2 with the GPL v3.  The most important changes introduced were in relation to software patents, free software license compatibility, the definition of "source code", and hardware restrictions on software modification. It is considered “viral” and negatively by some for-profit organizations.  I am not a fan of the GPL license because I feel it is too opinionated and tends to scare for-profit organizations away from open source.

• MIT License - Another permissive license that is similar to the Apache 2.0 license, and very short and loose regarding requirements.  The MIT license allows users to use, copy, and modify the software source code.  As the name would imply... this distribution license originates at the Massachusetts Institute of Technology... duh.  The MIT license is GPL-compatible, meaning that it can be combined with a program under the GPL license without conflict.  The MIT license is very similar to the BSD license.  The primary difference from the BSD license is that the BSD license contains a notice prohibiting the use of the name of the copyright holder in promotion.

• BSD License 2.0 - A permissive, free software license imposing minimal restrictions on the redistribution of covered software.  The BSD allows proprietary use and allows the software released under the license to be incorporated into proprietary products.  Similar to Apache 2.0 but lacks a patent grant, which means that the authors of the code are not giving rights needed for the authors' patents, which might happen to be in the code being used.  

My preferred open source license for use in the domain of healthcare information technology is the Apache 2.0 license.

For 7 years, I have successfully used the Apache 2.0 license for numerous healthcare projects that I have led.  The Apache 2.0 license is arguably the most commercial-friendly of all of these options due to wide adoption by industry, its permissive nature avoiding of “viral” requirements upon redistribution of derivative works, and the broad adoption of the associated Apache web server software which is used by most of commercial industry.

From my experience, one of the most important aspects of the Apache 2.0 license is the Apache brand.

Whenever I am telling a healthcare CIO about one of our open source projects licensed under the Apache 2.0 open source license, if they do not know the details of open source, I can usually talk them away from the ledge with Apache.  Talking about if they have/use an Apache web server, they usually they say "yes, I use an Apache web server".  At that point it is easier to explain that other software made available under an Apache 2.0 open source distribution license would represent no greater risk to viral release of an enterprise's intellectual property than using an Apache web server.

With the big disclaimer that I am not a lawyer... 

I also feel that the Apache 2.0 license is the superior distribution license to use in healthcare information technology because allows for software that is free to download, use, re-purpose, re-distribute, or even sell.  Yes, you are even allowed to sell someone else's software that is distributed via an Apache 2.0 license.  The only really hard requirements are attribution back to the copyright owner, and you cannot sue the original author if something bad happens.  That responsibility is on you, the user of the software.

By only requiring attribution, there is flexibility in the way that anyone would like use a derivative work.  If a healthcare open source project were to be better positioned as a paid commercial product, the Apache license provides for an immediate technology transfer mechanism to that market with no barriers... none.  Such a decision could even be made with or without agreement from all the open source project community that created the original project.  

While I am not endorsing that open source projects be "poached" and turned into commercial for-profit services, I do like that freedom that the Apache 2.0 license provides.

I hope this is helpful.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. © Rob McCready, 2014.

Designing Logos for a Portfolio of Healthcare Projects

Over the past three years, I have been involved with numerous open source healthcare projects, ranging from large reference implementations of Clinical Quality Measures, certification and testing tools adopted by the federal government, a small research project assessing CQM complexity/cost/tractability, this blog, and other ideas that failed to launch.

What I have been endorsing throughout the course of the past three years has been to establish a common "brand" that could be applied to various open source healthcare projects, but still provide a unique look and feel for each individual project.  

The design approach that organically evolved was to develop logos followed the following rules:

• Use only circles
• The circles may come in different sizes and arrangements
• Limiting the logos to a pallet of only two colors
• Color opacity could be changed

You can see the portfolio of these project logos below:

Portfolio of logos for open source healthcare projects I have worked on

Since I am a "left brain" engineer at heart, the various arrangements of the circles has been an easier task than color selection.  I have often struggled with finding the magic combination of colors for anything from these logos to our interior design of our hours.

The best resource that I have found been able to identify is ColorLovers.com.  For those not familiar with the site, it is an evolving resource for palettes and colors that users can share, rank and comment on.

When I had to select to colors, I went to the filter for "most loved" colors of all time, and tried to identify pallets where instead of 5 colors, there were 2 colors used in the pallet.  Hopefully this is a helpful trick.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. © Rob McCready, 2013.