Agile Health Services - A resource for the intersection of healthcare, computer science, and design

Health IT's journey from messages... to documents... to APIs

2014-12-16T14:18:00.001-05:00

The latest JASON report "Data for Individual Health" released last month continues to make the case for the adoption of open APIs to better support the interoperability of healthcare data. When I think back on the past ~25 years in Health IT, the story that this is painting feels like the gradual evolution of electronic health data from messages, to documents to APIs.

Clinical messages have always been an incomplete "soda straw" perspective of a very small amount of patient's clinical information. Messages are designed for communicating current information about a patient from one software system to another. HL7 v2 is the dominant industry standard used for expressing clinical messages.

HL7 v2 messages can be used to express different types of messages including Admissions and Discharges (ADT), Observation Result (ORU), Order Message (ORM). Additionally, HL7 v2 is a very old data standard, using a "pipe and hat format" approach to encoding the patient's clinical data. In order to parse an HL7 v2 message, you need to know the offset of data within an HL7 v2 message separated by "|" and "^" characters. For example, below is an example HL7 v2 message for a glucose reading.

MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930|
|ORU^R01|CNTRL-3456|P|2.4|PID|||555-44-4444|
|EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F|||
153 FERNWOOD DR.^^STATESVILLE^OH^35292||(206)3345232
|(206)752-121||||AC555444444||67-A4335^OH^20030520
|OBR|1|845439^GHH OE|1045813^GHH LAB|15545^GLUCOSE||
|200202150730||||||||
|555-55-5555^PRIMARY^PATRICIA P^^^^MD^^|||||||||F||
||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MD|OBX|1|SN
|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||F

This makes for a very brittle standard, that is machine interpretable, but not very easy to work with. By design, you probably would not want to persist HL7 v2 messages as the authoritative source of the clinical information about a patient. It is not going to be anything more than a soda straw of a few data points. To this end, moving forward to the turn of the 21st century... clinical documents could help... a little.

Clinical documents are designed to express a more complete picture of a patient's healthcare information at a specific date and point in time. Notable clinical document standards have included the ASTM CCR. HL7's CCD, CCDA, and QRDA Category I. MITRE also developed a standard for both representing and exchanging clinical documents called hData. Clinical documents differ from clinical messages in that documents are designed to contain more information extracted from an EHR system at a specific date and possibly a timestamp.

An example of an old CCR XML document representing a patient with hypertension and height/weight vitals follows:

<?xml version="1.0" encoding="UTF-8"?>
<ContinuityOfCareRecord xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:astm-org:CCR CCR_20051109.xsd http://www.w3.org/2001/XMLSchema xmldsig-core-schema.xsd" xmlns="urn:astm-org:CCR">
<CCRDocumentObjectID>94461c3f-7dbf-4af1-aba9-ed4aac26bea4</CCRDocumentObjectID>
<Language>
<Text>English</Text>
</Language>
<Version>V1.0</Version>
<DateTime>
<ExactDateTime>2010-02-01T15:52:04Z</ExactDateTime>
</DateTime>
<Body>
<Problems>
<Problem>
<CCRDataObjectID>BB0001</CCRDataObjectID>
<DateTime>
<Type>
<Text>Start date</Text>
</Type>
<ExactDateTime>1990-08-07T06:00:00Z</ExactDateTime>
</DateTime>
<Type>
<Text>Diagnosis</Text>
</Type>
<Description>
<Text>Hypertension</Text>
<Code>
<Value>403.10</Value>
<CodingSystem>ICD-9 CM</CodingSystem>
<Version>2005</Version>
</Code>
</Code>
</Description>
<Status>
<Text>Active</Text>
</Status>
</Problem>
</Problems>
<VitalSigns>
<Result>
<CCRDataObjectID>BB0009</CCRDataObjectID>
<DateTime>
<Type>
<Text>Start date</Text>
</Type>
<ExactDateTime>2005-09-24T04:00:00Z</ExactDateTime>
</DateTime>
<Description>
<Text>Height & Weight</Text>
</Description>
<Source>
<Actor>
<ActorID>AA0002</ActorID>
</Actor>
</Source>
<Test>
<CCRDataObjectID>BB0010</CCRDataObjectID>
<Type>
<Text>Observation</Text>
</Type>
<Description>
<Text>Height</Text>
<Code>
<Value>50373000</Value>
<CodingSystem>SNOMED</CodingSystem>
<Version>2005</Version>
</Code>
</Description>
<Source>
<Actor>
<ActorID>AA0002</ActorID>
</Actor>
</Source>
<TestResult>
<Value>155</Value>
<Units>
<Unit>cm</Unit>
</Units>
</TestResult>
</Test>
<Test>
<CCRDataObjectID>BB0011</CCRDataObjectID>
<Type>
<Text>Observation</Text>
</Type>
<Description>
<Text>Weight</Text>
<Code>
<Value>363808001</Value>
<CodingSystem>SNOMED</CodingSystem>
<Version>2005</Version>
</Code>
</Description>
<Source>
<Actor>
<ActorID>AA0002</ActorID>
</Actor>
</Source>
<TestResult>
<Value>55</Value>
<Units>
<Unit>kg</Unit>
</Units>
</TestResult>
</Test>
</Result>
</VitalSigns>
</Body>
<Actors>
<Actor>
<ActorObjectID>AA0001</ActorObjectID>
<Person>
<Name>
<CurrentName>
<Given>John</Given>
<Middle>N</Middle>
<Family>Doe</Family>
</CurrentName>
</Name>
<DateOfBirth>
<ExactDateTime>1960-08-23T06:00:00Z</ExactDateTime>
</DateOfBirth>
<Gender>
<Text>Male</Text>
</Gender>
</Person>
<IDs>
<Type>
<Text>SSN</Text>
</Type>
<ID>555-55-5555</ID>
<Source>
<Actor>
<ActorID></ActorID>
</Actor>
</Source>
</IDs>
<Address>
<Type>
<Text>Home</Text>
</Type>
<Line1>Main Street</Line1>
<City>Fort Lauderdale</City>
<State>FL</State>
<PostalCode>33011</PostalCode>
</Address>
<Source>
<Actor>
<ActorID>AA0002</ActorID>
</Actor>
</Source>
</Actor>
</ContinuityOfCareRecord>

This allows for additional data to express a more complete (but admittedly incomplete) picture of that patient's health.

Fast forward to today... as laid out in the latest JASON report... the trend is less towards messages or documents, and more towards open Application Programmer Interfaces (APIs) to access and exchange a patient's data.

In the FHIR RESTful framework, transactions are performed on the server using the HyperText Transfer Protocol (HTTP) request/response. FHIR's RESTful framework allows for services to create, read, update, and delete information exchanged from one service to another over a network.

There's levels of authentication to gate access that can be built into FHIR at various levels of a patient's record. So, if you wanted to request all the clinical information about a patient from a service, you would simply perform a "GET" request on that patient's identifier. Similarly, you could request a subset of finer levels of granularity for information such as that patient's conditions, medications, allergies, etc.

There are even some sexy things that you can do with FHIR's search capabilities of clinical data. For instance, you could perform search for any patient with a gender that has a code "male" with a query like:

GET [base-url]/Patient?gender=male

The data exchanged with FHIR is still clinical documents, but there's now a shift away from the CDA-based HL7 documents that I have not been a fan of, to FHIR's own approach to expressing clinical documentation with FHIR resources within the FHIR RESTful API.

Ultimately, I think this is where we should be going; both with focusing on how data will be accessed and exchanged while simultaneously ensuring that the clinical data used between different services is designed to be simpler and stricter.

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

Bonnie: An Open Source Clinical Quality Measure Testing Tool

2014-10-14T16:54:00.000-04:00

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.

Example of CDA limitations to interoperability: time intervals

2014-10-08T15:03:00.000-04:00

The HL7 Clinical Document Architecture (CDA) is an XML-based markup standard intended to specify the encoding, structure and semantics of clinical documents for exchange. CDA is an ANSI-certified standard from Health Level Seven (HL7). The CDA is highlighted as a flexible framework that can contain any type of clinical content. Additionally, the details of the encoding of clinical data and associated aspects of that data are intentionally designed to be flexible.

That flexibility provides freedoms in various different systems' ability to export clinical data. However, that same flexibility is an increasing barrier to the interoperability of data as systems need to import that same data. My biggest pet peeve with the CDA and this problem is the flexibility that the CDA provides in the encoding of time intervals.

Based on clinical reason, the CDA provides the freedom to encode time intervals in eight (8) (VIII) different representations.

<low>
<width>
<high>
<low> <width>
<low> <high>
<center>
<center> <width>

This amount of flexibility in expressing something as simple as a time interval is an obstacle for any receiving system hoping to import and parse an HL7 CDA-based XML document without knowing the way that the generating system is going to express something as basic as a time interval. This permissive nature of the CDA's artifacts is common beyond this one basic example.

What is needed, and hopefully addressed in the emerging FHIR specification, is a more constrained approach to the foundational aspects of clinical data, such as how to encode time intervals. To reach a point with more interoperability of healthcare data, analysis is needed of the presence of types of structured clinical data concepts and associated clinical codes used operationally.

I feel that the healthcare standards community ultimately needs to identify a strict and simple constrained set of ways of expressing clinical concepts that healthcare Standards Development Organizations (SDOs) like HL7 should use to constrain existing permissive and complex standards. This could also be done to guide a stricter and simpler implementation to support interoperability via FHIR.

This could introduce significant and radical improvements in the interoperability of patient data in the US healthcare industry. This will better enable disparate healthcare software systems to work together without requiring point-to-point coordination. This could reduce, and eventually eliminate, these problems of point-to-point coordination that result in islands of automation.

This "loose coupler" approach will encourage HL7, or possibly new healthcare SDOs, to embrace a core set of strict and simple required attributes, over the current state of the practice using permissive and complex attributes.

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

ICD 10 vs ICD 9 Code Format Structural Differences

2014-08-05T19:01:00.003-04:00

ICD is the World Health Organization's (WHO's) International Classification of Diseases (ICD) and Related Health Problems and is the international standard diagnostic classification system, and is the tenth revision of the ICD. The ICD is the coding system which physicians and other healthcare providers currently use to code all diagnoses, symptoms, and procedures recorded in hospitals and physician practices.

It is a big deal.

Today, the Department of Health and Human Services (HHS) just published an updated rule for the adoption of ICD-10 code sets. HHS is requiring that all HIPAA covered entities must be ICD-10 compliant by October 1st, 2015. This newly updated compliance date is meant to be firm and not subject to any change. This is the third time that ICD-10 has been delayed, so I strongly suspect that this new deadline will be met by next fall.

Last year, I put together a visualization of analysis of the ICD-10 coding landscape. Below is a simple primer explaining the distinction between ICD-9 and ICD-10, demonstrating structurally the difference in the two coding systems. In particular, the ICD-10 code set has been expanded from five positions (first one alphanumeric, others numeric) to up to seven positions. The codes use alphanumeric characters in all positions, not just the first position as in ICD-9.

ICD-9 vs ICD-10 coding

Some other interesting artifacts of ICD-9 vs ICD-10 that I discovered today:

As of the latest version, there are ~68,000 codes in ICD-10, as opposed to the ~13,000 in ICD-9. More specifically, there are nearly 5 times as many diagnosis codes in ICD-10 than in ICD-9 and there are nearly 19 times as many procedure codes in ICD-10 than in ICD-9. Yikes!
The new code set provides a significant increase in the specificity of the reporting, allowing more information to be conveyed in a code. To support this, the terminology has been modernized and has been made consistent throughout the code set. There are codes that are a combination of diagnoses and symptoms, with a claim that fewer codes need to be reported to fully describe a condition.

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

2014-07-23T22:27:00.002-04:00

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.

Conceptual Hospital Dashboard Design

2013-11-22T17:15:00.002-05:00

I have been neglecting the "design" aspect of this blog for some time. To re-engergize the need for more engaging content, to put some eye-candy out... and have some fun on a late Friday afternoon… I thought I would share a shelved design for a dashboard that I developed for a COO at a notional hospital:

Notional Hospital COO Dashboard Design

I have made several assumptions when coming up with this mockup. The first is that quality and quality metrics would be of utmost importance to this user. Maybe pay-for-performance programs have been adopted based on Clinical Quality Measures (CQMs), and quality issues have an immediate impact on the bottom line of the organization. I included both a kiviat visualization for showing targets against measured results for CQMs, and a longitudinal trend for those CQMs over time.

With the disclaimer that I am not a clinician; I made some assumptions that knowing the types of procedures that are being performed, and when those procedures deviate from expected norms is something else that a COO would track.

Lastly, I am showing a design technique that Stephen Few will sometimes use to provide a non-white background to reduce eyestrain. Having met him several years ago, I am a fan of Stephen's work. I always like the muted background color that he tends to include in his works.

I welcome the feedback.

Kudos if you "get" the names of the ten physicians.

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

Example QRDA Category 3 XML for Meaningful Use Stage 2 Clinical Quality Measure Reporting

2013-11-14T20:09:00.003-05:00

I have been preparing to lead a summit in D.C. tomorrow to discuss versioning of the various Meaningful Use Clinical Quality Measure (CQM) standards. During final preparation for the summit, I have been digging into the QRDA Category 3 XML specification. As I detailed a few months ago, the QRDA Category 3 XML is used for reporting aggregate data for reporting CQMs. The more that I go spelunking into the QRDA Category 3 standard, the more I understand the complexities associated with it. I am hoping that providing an example QRDA Category 3 XML will be helpful to the broader community.

Detailed below is a (verbose) example QRDA Category 3 XML file for expressing the Meaningful Use Stage 2 Clinical Quality Measure for expressing the results for "NQF 0018 Controlling High Blood Pressure". Assume that this CQM is being considered against a population of patients that would generate aggregate section results that would look like this:

Initial Patient Population (IPP): 3
Denominator: 3
Numerator: 1
Exceptions: 1
Exclusions: 0

Additionally, Electronic Health Record (EHR) systems are required to report on the supplemental data for sex, ethnicity, race and payer. So for this data set, assume that there are two males that meet the IPP and only one female. Then, assume only one of the males meets the numerator requirement. For simplicity, assume that we do not have any information on race, ethnicity, or payers… so assume "unknown" for all the patients on those dimensions.

Scrolling below, I enumerate a valid example QRDA Category 3 XML file and the sections used to report the aggregate results via CQM QRDA Category 3. I highlighting the aggregate section results with a yellow background, and the supplemental data with a violet background.

Similar to the QRDA Category 1, it is really difficult to understand why there is so much XML bloat here. For expressing the CQM results I enumerated after the third paragraph of this blog entry, it takes 679 lines of XML to express these results in the QRDA Category 3! It is a real struggle to attempt to explain why so much verbose XML is needed to convey such little aggregate information.

With a more detailed understanding of the QRDA Category 3 specification, I think it is finally time to seriously question the ongoing use of the HL7 Clinical Document Architecture (CDA) and the HL7 Reference Implementation Model (RIM) for expressing any type of healthcare data in XML. While I appreciate what the leaders at HL7 are attempting to do, the QRDA Category 3 XML bloat is probably the best (worst?) example I have seen to support use of a simpler and less complex standard that deviates from the CDA and RIM.

Steve Jobs quote that needs to be considered here “Simple can be harder than complex. You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.” See the evidence of the need for this type of change below:

<?xml version="1.0" encoding="utf-8"?>
<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:hl7-org:v3" xmlns:cda="urn:hl7-org:v3">
<realmCode code="US"/>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<templateId root="2.16.840.1.113883.10.20.27.1.1"/>
<id root="9c9762c0-2ac3-0131-4e2f-0050560100a9"/>
<code code="55184-6" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC"
displayName="QRDA Category 3 Summary Report"/>
<title>QRDA Category 3 Calculated Summary Report</title>
<effectiveTime value="20131108164909"/>
<confidentialityCode codeSystem="2.16.840.1.113883.5.25" code="N"/>
<languageCode code="en-US"/>
<versionNumber value="1"/>
<recordTarget>
<patientRole>
<id nullFlavor="NA"/>
</patientRole>
</recordTarget>
<author>
<time value="20131108164909"/>
<assignedAuthor>
<id extension="Foo" root="Bar"/>
<assignedAuthoringDevice>
<softwareName/>
</assignedAuthoringDevice>
<representedOrganization>
<id root="root" extension="ext"/>
<name/>
</representedOrganization>
</assignedAuthor>
</author>
<custodian>
<assignedCustodian>
<representedCustodianOrganization>
<id root="root"/>
<name>Some Custodian Name</name>
</representedCustodianOrganization>
</assignedCustodian>
</custodian>
<legalAuthenticator>
<time value="20131108164909"/>
<signatureCode code="S"/>
<assignedEntity>
<id root="root"/>
<representedOrganization>
<id root="root"/>
</representedOrganization>
</assignedEntity>
</legalAuthenticator>
<component>
<structuredBody>
<component>
<section>
<templateId root="2.16.840.1.113883.10.20.17.2.1"/>
<templateId root="2.16.840.1.113883.10.20.27.2.2"/>
<code code="55187-9" codeSystem="2.16.840.1.113883.6.1"/>
<title>Reporting Parameters</title>
<text>
<list>
<item>Reporting period Dec 31 2011 -
Dec 31 2012</item>
</list>
</text>
<entry typeCode="DRIV">
<act classCode="ACT" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.17.3.8"/>
<code code="252116004"
codeSystem="2.16.840.1.113883.6.96"
displayName="Observation Parameters"/>
<effectiveTime>
<low value="20111231120000"/>
<high value="20121231120000"/>
</effectiveTime>
</act>
</entry>
</section>
</component>
<component>
<section>
<templateId root="2.16.840.1.113883.10.20.24.2.2"/>
<templateId root="2.16.840.1.113883.10.20.27.2.1"/>
<code code="55186-1" codeSystem="2.16.840.1.113883.6.1"/>
<title>Measure Section</title>
<text></text>
<entry>
<organizer classCode="CLUSTER" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.24.3.98"/>
<templateId root="2.16.840.1.113883.10.20.27.3.1"/>
<statusCode code="completed"/>
<reference typeCode="REFR">
<externalDocument classCode="DOC" moodCode="EVN">
<id root="40280381-3D61-56A7-013E-66BC02DA4DEE"/>
<text>Controlling High Blood Pressure</text>
<setId
root="ABDC37CC-BAC6-4156-9B91-D1BE2C8B7268"/>
<versionNumber value="1"/>
</externalDocument>
</reference>
<component>
<observation classCode="OBS" moodCode="EVN">
<templateId
root="2.16.840.1.113883.10.20.27.3.14"/>
<code code="72510-1"
codeSystem="2.16.840.1.113883.6.1"
displayName="Performance Rate"
codeSystemName="2.16.840.1.113883.6.1"/>
<statusCode code="completed"/>
<value xsi:type="REAL" value="0.5"/>
<reference typeCode="REFR">
<externalObservation classCode="OBS"
moodCode="EVN">
<id
root="5EE417A9-32DB-452F-BAA0-74C5831A4457"/>
<code code="NUMER" displayName="Numerator"
codeSystem="2.16.840.1.113883.5.1063"
codeSystemName="ObservationValue"/>
</externalObservation>
</reference>
</observation>
</component>
<component>

<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.5"/>
<code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"
displayName="Assertion" codeSystemName="ActCode"/>
<statusCode code="completed"/>
<value xsi:type="CD" code="IPP"
codeSystem="2.16.840.1.113883.5.1063"
codeSystemName="ObservationValue"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="3"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId
root="2.16.840.1.113883.10.20.27.3.6"/>
<id nullFlavor="NA"/>
<code code="184100006"
codeSystem="2.16.840.1.113883.6.96"/>
<statusCode code="completed"/>
<value xsi:type="CD" code="F"
codeSystem="2.16.840.1.113883.5.1"/>
<entryRelationship typeCode="SUBJ"
inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="1"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.6"/>
<id nullFlavor="NA"/>
<code code="184100006"
codeSystem="2.16.840.1.113883.6.96"/>
<statusCode code="completed"/>
<value xsi:type="CD" code="M"
codeSystem="2.16.840.1.113883.5.1"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="2"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.7"/>
<id nullFlavor="NA"/>
<code code="364699009"
codeSystem="2.16.840.1.113883.6.96"/>
<statusCode code="completed"/>
<value xsi:type="CD" nullFlavor="UNK"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="3"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.8"/>
<id nullFlavor="NA"/>
<code code="103579009"
codeSystem="2.16.840.1.113883.6.96"/>
<statusCode code="completed"/>
<value xsi:type="CD" nullFlavor="UNK"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="3"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.9"/>
<id nullFlavor="NA"/>
<code code="48768-6" codeSystem="2.16.840.1.113883.6.1"/>
<statusCode code="completed"/>
<value xsi:type="CD" nullFlavor="UNK"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="3"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>
<reference typeCode="REFR">
<externalObservation classCode="OBS" moodCode="EVN">
<id root="B936D6B5-151F-47FB-97D8-A5AB9AB00656"/>
</externalObservation>
</reference>
</observation>
</component>
<component>

<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.5"/>
<code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"
displayName="Assertion" codeSystemName="ActCode"/>
<statusCode code="completed"/>
<value xsi:type="CD" code="DENOM"
codeSystem="2.16.840.1.113883.5.1063"
codeSystemName="ObservationValue"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="3"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.6"/>
<id nullFlavor="NA"/>
<code code="184100006"
codeSystem="2.16.840.1.113883.6.96"/>
<statusCode code="completed"/>
<value xsi:type="CD" code="F"
codeSystem="2.16.840.1.113883.5.1"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="1"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.6"/>
<id nullFlavor="NA"/>
<code code="184100006"
codeSystem="2.16.840.1.113883.6.96"/>
<statusCode code="completed"/>
<value xsi:type="CD" code="M"
codeSystem="2.16.840.1.113883.5.1"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="2"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.7"/>
<id nullFlavor="NA"/>
<code code="364699009"
codeSystem="2.16.840.1.113883.6.96"/>
<statusCode code="completed"/>
<value xsi:type="CD" nullFlavor="UNK"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="3"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.8"/>
<id nullFlavor="NA"/>
<code code="103579009"
codeSystem="2.16.840.1.113883.6.96"/>
<statusCode code="completed"/>
<value xsi:type="CD" nullFlavor="UNK"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="3"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.9"/>
<id nullFlavor="NA"/>
<code code="48768-6" codeSystem="2.16.840.1.113883.6.1"/>
<statusCode code="completed"/>
<value xsi:type="CD" nullFlavor="UNK"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="3"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>
<reference typeCode="REFR">
<externalObservation classCode="OBS" moodCode="EVN">
<id root="2A53CBF0-510A-429D-814D-CBCA4DC0E2A8"/>
</externalObservation>
</reference>
</observation>
</component>
<component>

<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.5"/>
<code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"
displayName="Assertion" codeSystemName="ActCode"/>
<statusCode code="completed"/>
<value xsi:type="CD" code="NUMER"
codeSystem="2.16.840.1.113883.5.1063"
codeSystemName="ObservationValue"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="1"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.6"/>
<id nullFlavor="NA"/>
<code code="184100006"
codeSystem="2.16.840.1.113883.6.96"/>
<statusCode code="completed"/>
<value xsi:type="CD" code="M"
codeSystem="2.16.840.1.113883.5.1"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="1"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.7"/>
<id nullFlavor="NA"/>
<code code="364699009"
codeSystem="2.16.840.1.113883.6.96"/>
<statusCode code="completed"/>
<value xsi:type="CD" nullFlavor="UNK"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="1"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.8"/>
<id nullFlavor="NA"/>
<code code="103579009"
codeSystem="2.16.840.1.113883.6.96"/>
<statusCode code="completed"/>
<value xsi:type="CD" nullFlavor="UNK"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="1"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.9"/>
<id nullFlavor="NA"/>
<code code="48768-6" codeSystem="2.16.840.1.113883.6.1"/>
<statusCode code="completed"/>
<value xsi:type="CD" nullFlavor="UNK"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="1"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>
<reference typeCode="REFR">
<externalObservation classCode="OBS" moodCode="EVN">
<id root="5EE417A9-32DB-452F-BAA0-74C5831A4457"/>
</externalObservation>
</reference>
</observation>
</component>
<component>

<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.5"/>
<code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"
displayName="Assertion" codeSystemName="ActCode"/>
<statusCode code="completed"/>
<value xsi:type="CD" code="DENEX"
codeSystem="2.16.840.1.113883.5.1063"
codeSystemName="ObservationValue"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="1"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.6"/>
<id nullFlavor="NA"/>
<code code="184100006"
codeSystem="2.16.840.1.113883.6.96"/>
<statusCode code="completed"/>
<value xsi:type="CD" code="F"
codeSystem="2.16.840.1.113883.5.1"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="1"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.7"/>
<id nullFlavor="NA"/>
<code code="364699009"
codeSystem="2.16.840.1.113883.6.96"/>
<statusCode code="completed"/>
<value xsi:type="CD" nullFlavor="UNK"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="1"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">=
<templateId root="2.16.840.1.113883.10.20.27.3.8"/>
<id nullFlavor="NA"/>
<code code="103579009"
codeSystem="2.16.840.1.113883.6.96"/>
<statusCode code="completed"/>
<value xsi:type="CD" nullFlavor="UNK"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="1"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>

<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.9"/>
<id nullFlavor="NA"/>
<code code="48768-6" codeSystem="2.16.840.1.113883.6.1"/>
<statusCode code="completed"/>
<value xsi:type="CD" nullFlavor="UNK"/>
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.27.3.3"/>
<code code="MSRAGG" displayName="rate aggregation"
codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActCode"/>
<value xsi:type="INT" value="1"/>
<methodCode code="COUNT" displayName="Count"
codeSystem="2.16.840.1.113883.5.84"
codeSystemName="ObservationMethod"/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>
<reference typeCode="REFR">
<externalObservation classCode="OBS" moodCode="EVN">
<id root="57F3D1D7-F9FA-437F-A2B9-406A1498E8C0"/>
</externalObservation>
</reference>
</observation>
</component>
</organizer>
</entry>
</section>
</component>
</structuredBody>
</component>
</ClinicalDocument>

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

Visualization of ICD-10 Code Counts

2013-11-02T14:21:00.001-04:00

This past week I have been working in the bowels of the QRDA Category 1 XML for the popHealth project that we are deploying for the Veterans Health Administration (VHA). In the process of working with the QRDA Category 1, I had to resuscitate some of my Ruby and REXML skills that had atrophied in the past year.

This weekend, I wanted to shakeout some of my technical skills in a cleaner environment and downloaded the XML for the full set of ICD-10 codes from the CMS site.

Why ICD-10? It is the 10th revision of the International Statistical Classification of Diseases and Related Health Problems (ICD) by the World Health Organization (WHO). ICD-10 provides a hierarchy of structured codes for diseases, symptoms, findings, complaints, social circumstances, and external causes of injury/diseases. The big national issue related to ICD-10 is that it will be required for expressing claims data to the Center for Medicare and Medicaid Services (CMS) starting on October 2014.

The current state-of-the-practice for capturing this coded data in Electronic Health Record systems is (IMHO) still ICD-9, the predecessor to ICD-10. One of the biggest differences between ICD-9 and ICD-10 is the fidelity of data that can be captured in ICD-10. In particular, there are over 68,000 distinct codes in ICD-10 as opposed to the roughly 13,000 in ICD-9.

Working with the XML file provided on the CMS site that details the ICD-10 code hierarchy, I wanted to see if I could convert the data into a format that would allow me to visualize the code counts into a D3.js example. I figured it was good to exercise some XML knowledge outside of the complexity of the QRDA Category 1 XML. Further,I wanted to learn a little more about the structure of the ICD-10 codes.

It is worth noting that the CMS ICD-10 XML is surprisingly easy to understand for the purposes of enumerating the full set of codes and the hierarchy. The QRDA Category 1 XML… not so easy to understand.

What I did was to load the ICD-10 XML hierarchy into a simple Ruby program via REXML. I created a aggregate count in a hash table of the second-level codes in the ICD-10 hierarchy by traversing the XML file. I had to do this only at the second-level of the ICD-10 hierarchy because the sheer number of third-level ICD-10 codes broke the D3.js visualization examples. To explain this a little more, the hierarchy of an example diabetes code down that the fourth level in ICD-10 follows:

E00-E89: Endocrine, nutritional and metabolic diseases
|-> E08 Diabetes mellitus due to underlying condition
|->E08.2 Diabetes mellitus due to underlying condition with kidney complications
|->E08.22 Diabetes mellitus due to underlying condition with diabetic chronic kidney disease

So for the illustration of ICD-10 code counts, I stopped aggregating at just the second level of the hierarchy and count/aggregate codes from the third and forth levels. Each tiny square in the illustration below represents the counts of just the second level of the ICD-10 space of roughly 68,000 total codes.

Once I had the counts of individual ICD-10 codes aggregated at second-level of the ICD-10 hierarchy, I exported a JSON file that could work with the D3.js example that I picked. Below is a thumbnail (admittedly... illegible) of the ICD-10 code counts transformed with the D3.js treemap example.

Visualization of second level ICD-10 code counts

If you want to try and download a higher resolution image of the ICD-10 codes and actually read more of the details, click here. HEADS UP… it is gianormous.

With the illustration, starting from left-to-right and then top-to-bottom, the sections in the ICD-10 data set that coincide with the colors in the illustration as follows. The only confusing item is the last "chapter" from ICD-10 is the gray box in the bottom left "Factors influencing health status and contact with health services". I think the D3.js code had to try and fit that section into the illustration.

A00-B99: Certain infectious and parasitic diseases
C00-D49: Neoplasms
D50-D89: Diseases of the blood and blood-forming organs and certain disorders involving the immune mechanism
E00-E89: Endocrine, nutritional and metabolic diseases
F01-F99: Mental, Behavioral and Neurodevelopmental disorders
G00-G99: Diseases of the nervous system
H00-H59: Diseases of the eye and adnexa
H60-H95: Diseases of the ear and mastoid process
I00-I99: Diseases of the circulatory system
J00-J99: Diseases of the respiratory system
K00-K95: Diseases of the digestive system
L00-L99: Diseases of the skin and subcutaneous tissue
M00-M99: Diseases of the musculoskeletal system and connective tissue
N00-N99: Diseases of the genitourinary system
O00-O9A: Pregnancy, childbirth and the puerperium
P00-P96: Certain conditions originating in the perinatal period
Q00-Q99: Congenital malformations, deformations and chromosomal abnormalities
R00-R99: Symptoms, signs and abnormal clinical/laboratory findings, not elsewhere classified
S00-T88: Injury, poisoning and certain other consequences of external causes
V00-Y99: External causes of morbidity
Z00-Z99: Factors influencing health status and contact with health services

If you are interested, you can access the JSON file with the second level code counts from my GitHub repository that I setup.

Further, you could use this JSON with several other data hierarchy examples off the D3.js site if you are interested. They use the same JSON format for representing the data, and you should be able to just drop the JSON that I created into that HTML if you tweak the name of the file in the examples and set your width and height of the demo to about one thousand times greater than what is provided since the about of data is so large.

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

Meaningful Use Stage 2 Clinical Quality Measure Analysis Against Live Patient Data

2013-10-31T12:23:00.000-04:00

The Meaningful Use Stage 2 Clinical Quality Measures (CQMs) reference a wide variety of clinical data elements. As part of the Kamira research project that I am wrapping up, we jointly developed a paper that describes the results of a study with the Massachusetts eHealth Collaborative (MAeHC). The purpose of the paper was to determine data elements which are present in a large operational patient population and to describe the impact of missing data elements as components to the CQMs.

The full paper is publicly available on the Kamira site here.

To highlight, some of the results of the study determine the presence or absence of each of the clinical codes used in MU2 CQM data elements using a large set of patient data (500k patient records covering 5M care events) collected by MAeHC. The results were used to determine the impact on the MU2 CQMs at two levels:

Clinical data elements were ranked according to the intersection of their component clinical codes and the codes present in the patient data
CQM populations were classified according to the ranks of their component clinical data elements.

The results of this analysis were then used to determine which CQMs are likely to work well with the patient data and which require data that is not present.

Some key findings of the paper include:

The majority of the clinical codes used in value sets referred to by the MU2 CQMs are not found in patient data. Very few of the SNOMED (0.03%) and LOINC (2%) codes used in MU2 CQMs are found in the patient data.
Many value sets do not contain any codes that are present in the patient data: across all measures over half of the MU2 CQM value sets contain no codes. Such value sets are referred to as non-intersecting.
There are many measure populations containing only non-intersecting value sets. Across all measures, nearly 60% of distinct denominators and 27% of numerators reference only data that is not present in the patient records. Such measures will, by definition, report 0/0 or 0/n results.

Below is an illustration taken from the paper that details code occurrence of what is available in Meaningful Use Stage 2 for ICD-9, LOINC, SNOMED, CPT, CVX and RxNorm. Each bar represents all of the codes from the respective code system defined in Meaningful Use Stage 2 for the Eligible Professional CQMs. The blue segments of each bar show the percentage of codes that are present in the system.

Another compelling illustration is the value set intersection results. A value set contains one or more codes from one or more clinical vocabularies for a clinical concept, like "Diabetes". Given the code occurrence results above it is possible to compute the intersection of each Meaningful Use Stage 2 CQM value set with the patient data as follows: I=P/T where I is the intersection, P represents the number of codes in the value set that are present in the data and T represents the total number of codes in the value set.

Below, each bar represents the total number of value sets for either both Eligible Hospital and Eligible Professional CQMs (All), just the Eligible Hospital (EH) CQMs, or Eligible Professional (EP) CQMs. Each bar is subdivided to show the proportion of value sets with different levels of intersection.

A key takeaway from this paper is that the majority of the codes used in the value sets referred to by the Meaningful Use Stage 2 Eligible Professional CQMs are not found in the operational patient data.

Only finding a minority of the codes would not necessarily be a problem... value sets may contain many codes and provided one of those codes is present in the patient data, the corresponding data element will be also be satisfied. Unfortunately, the value set intersection results show that many value sets contain no codes actually present in the patient data. Across all measures over half of the MU2 CQM value sets contain no codes. The primary reason for non-intersecting value sets is choice of code sets: 73% of the non-intersecting value sets include only some combination of SNOMED-CT, LOINC and ICD-10 codes. All of these are scarce in the live/operational patient data.

Additionally, the non-intersecting value sets are not distributed evenly across all measure populations where their impact would be lessened. Instead, there are many CQM populations containing only non-intersecting value sets. Across all measures, nearly 60% of distinct denominators and 27% of numerators reference only data that is not present. Such CQMs will, by definition, report 0/0 or 0/n results… every time. Yikes!!!

Admittedly, this is only one sample point of data using a single practice. However, it is data from coded clinical source used by a national leader in healthcare information technology. If this issue is present in other operational EHR systems (as I strongly suspect) the only way to address this problem moving forward in MU Stage 3 will be to re-consider the required clinical codes that need to be capture in the EHR systems used operationally... or refine the translations from clinical concepts to clinical codes.

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

popHealth v2.4 Design for Meaningful Use Stage 2

2013-10-16T12:27:00.002-04:00

As some of you know, I have been leading the open source popHealth project at MITRE for the past 4 years. The MITRE popHealth team is currently working for the Veterans Health Administration (VHA). Our work is focused on using popHealth as the software service allow the VHA to meet Meaningful Use Stage 2 certification for Clinical Quality Measures (CQMs).

Since we hadn't been working on popHealth in any substantial level in most of 2013, so we identified some problems for ongoing operations and maintenance (O&M) of the popHealth software when we started to put more and more engineers back on the project. The concerns that the popHealth team had was the software that manages the User Interface (UI) presentation layer in the browser was becoming too complex and convoluted. This had the potential for introducing difficulty when a non-MITRE contractor will eventually manage the popHealth software in an "O&M" mode for the VHA. This will happen when our team completes the development task and moves off of this project.

What the popHealth team opted to do was to clean up the JavaScript and HTML so that there was an Application Programming Interface (API) that could provide JavaScript Object Notation (JSON) for the popHealth data needed for the UI directly to the browser. This is a cleaner software design that also allows user to forgo the existing popHealth UI if they need to provide just the raw CQM data.

In the process of refactoring the popHealth web application infrastructure, the team opted to introduce some tweaks to the popHealth presentation layer but still maintain the existing interaction model. What we decided to do was only slightly evolve the existing popHealth branding and look and feel, so that is is more maintainable from an engineers perspective, but does not introduce a radically different interaction model require re-training for all our existing users.

The popHealth v1.4 user interface that was aligned with the Meaningful Use Stage 2 program is below:

popHealth v1.4 Dashboard Design for Meaningful Use Stage 1

In the process of refactoring the popHealth web application infrastructure, the popHealth design team opted to introduce some tweaks to the presentation layer but still maintains the established L&F and interaction model. The latest updated designs for popHealth v2.4 follow:

popHealth v2.4 Dashboard Design for Meaningful Use Stage 2

Changes in the evolved popHealth v2.4 design include:

Eliminated confusing links for the "parameters" of each CQM on the right; now, there is just a link to access the patients.
Reduced the number of colors and focused on a more muted and simplified color pallet
Eliminated the single horizontal bar visualization and replaced it with two stacked bars for the fractions
Identified the exception and exclusion population with muted gray bars on the stacked bar charts
Enhanced the performance rate fraction with a visual radial circle around the fraction value

If anyone has opinions on the latest designs, the team welcomes any and all constructive feedback.

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

Applying Cost To Clinical Quality Measures

2013-07-10T18:52:00.000-04:00

With the Kamira research project that I am leading, our team was able to instrument the Meaningful Use (MU) Stage 2 Clinical Quality Measure (CQM) logic with the procedural logic for calculating the results of the CQMs via the popHealth project. What this popHealth CQM calculation software provided the Kamira team was the clinical building blocks of the CQM logic, which we were able to marry with publicly available claims data hosted by CMS based on de-identified real-life claims records.

With the CQM calculation land this collection of claims records, we were able to asses ranges of the cost associated with addressing the MU Stage 2 CQMs. With this, we were able to provide a guess for how much cost would be introduced into the healthcare system if a provider were to attempt to address the numerator logic of an MU Stage 2 CQM.

Consider the MU Stage 2 CQM "NQF 0062: Diabetes Urine Protein Screening". This CQM measures the percentage of patients 18-75 years of age diagnosed with diabetes who had a some form of urine screening during the measurement period. However, if you look at the conditional logic of this CQM, you can see that having the dialysis procedure would

Procedural numerator logic for "NQF 0062: Diabetes Urine Protein Screening"

When we applied the CMS claims data, you can see the wide range of costs associated with this particular CQM's numerator logic, spanning microalbumin testing, ACE inhibitor, and access to dialysis:

Numerator costs on NQF 0062 - Diabetes Urine Protein Screening

As a non-clinician, the first two tests in the numerator logic make sense to me (microalbumin lab tests). They appear to be in the "spirit" of this CQM, measuring if the provider has performed the microalbumin lab test for kidney damage. However, the Kamira automated cost assessment highlighted that the vascular access for dialysis is clearly a much more expensive procedure to address this numerator logic than the lab test. We didn't have any claims data on the kidney transplant from our sample set, but I can only speculate that the cost for that claim would be in the six figure range.

Looking purely at the CQM logic, and not applying any clinical perspective on this CQM, the vascular access for dialysis procedure is viewed as equivalent to the microalbumin lab test, at least within the scope of in this CQM logic. Both are equal when assessing if the provider is performing the best quality of care for their population of diabetic patients. Again... a kidney transplant is also in that same category as being semantically equivalent to the microalbumin lab test!!!

On the flip side, it appears to me that vascular access for dialysis is meant to address a known clinical problem, whereas the microalbumin lab test is designed to only collect and present information to a provider. This difference in the clinical purpose of the clinical activities is not considered in the CQM logic. Again, the CQM logic views both as equivalent when measuring the quality of care that a provider is applying to their population of patients.

Based on the Kamira automated CQM cost analysis, my recommendation is to groom the logic of "NQF 0062: Diabetes Urine Protein Screening", and re-position the dialysis procedure probably belongs in the exception or exclusion logic, vs. the current numerator logic. There are some additional opportunities to apply this cost consideration on all Meaningful Use Stage 3 CQMs. By applying these cost metrics to the MU Stage 3 CQMs, at minimum, the policy makers could discuss the impact of cost with the numerator logic clinical data. Additionally, these conversations could potentially lead to streamlining and pruning the MU Stage 3 CQM logic to avoid noisy and high variance healthcare costs within the logic of one CQM.

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

Thoughts on Clinical Quality Measure and Clinical Decision Support Convergence

2013-06-06T18:51:00.000-04:00

I have been tracking several discussions for the past year to consider the convergence of Clinical
Quality Measures and Clinical Decision Support within Electronic Health Record systems. As a quick refresher on the two types of healthcare reports:

Clinical Quality Measurement (CQM)

Typically post-event reporting on treatment, usually via a quarterly or annual basis
Longer term impact on healthcare quality of a population of patients

Clinical Decision Support (CDS)

Guide clinical choices during treatment now
More direct and immediate impact on the quality of care being provided to a patient

CQMs and CDS are clearly very closely related disciplines. In fact, they are two sides of the same coin. They both consider what actions providers take with the "hand they are dealt" with their patients. For both types of reports, data in input via electronic clinical data, and both are implemented within EHR systems. Additionally, the logic of a CDS rule and a CQM report are indeed very similar.

With CQMs, you are reviewing actions taken in the past to help educate and influence decisions in the future.

With CDS, you are working in real-time... in the present.

To put this in another context, with CQMs you may be viewing data that may have led to the death of a patient. The goodness or badness has been performed by the provider or healthcare team. With CDS, you have the potential to actually kill a patient by taking the wrong action.

This is the part of the CDS space that I personally find troubling to work with, since there is a much more real risk to harming a patient with either a bug in CDS logic or with ambiguity in standards that could be used to express CDS

Consider a Warfarin CQM that measures “Did you perform appropriate warfarin dosing?” You could apply this CQM to a population of cardiac patients and consider the results in aggregate to see if over the course of a year. Now consider a CDS that determines "What is the lethal dose of warfarin dosing that I am providing this patient... right now?!?”

For me, addressing the second scenario become really serious very quickly. For healthcare providers, I do not think that they are phased with either domain, since they deal with life and death scenarios all the time.

But again, for me, these are the scenarios and domains where I lose sleep after work.

Several considerations have been discussed to expand the Health Quality Measures Format (HQMF) XML standard that is used for expressing the CQM logic for the Meaningful Use program. The HQMF is an HL7 standard for representing a Clinical Quality Measure (CQMs) in XML. The HQMF standard is a declarative approach to defining procedural CQM reporting logic. What the HQMF standard has going for it, is (regrettably) being named the authoritative source for expressing the logic for the Meaningful Use Stage 2 CQMs.

The HQMF implementation of CQMs defines the data elements referenced by the logic, and associates them to value sets using object identifiers (OIDs). These OIDs can then be used with the National Library of Medicine's (NLM's) Value Set Authority Center (VSAC) to translate clinical concepts into various operational clinical codes.

For those really interested in using the HQMF, you can download the HQMF files for all the Meaningful Use Stage 2 Clinical Quality Measures from the CMS site here.

Having worked with the HQMF XML standard indirectly for the past 2 years on both the popHealth project, and for the past year the Cypress project, my team has repeatedly expressed concern over the standard due to ambiguity and difficulty in ensuring that the HQMF standard is properly implemented in an EHR. For our team, our challenge was consuming HQMF XML and turning it into procedural logic for Cypress and popHealth.

Based on the challenges my team has faced, I am very cautious about any considerations to re-use the HQMF standard for CDS support, since I feel it does a poor job expressing even the CQM logic. My primary concern with the plans on converging CQMs and CDSs logic is the current declarative approach used for CQMs which is the HQMF XML standard.

What I feel is needed is a procedural definition of both CQM and CDS logic. The reason for this need for procedural expression of the logic is that it allows for more rigorous testing, and also reduces the ambiguity associated with EHR systems have to implement their own parser to convert the declarative HQMF definition of either a CQM or CDS into their own procedural set of software instructions.

Consider the following procedural JavaScript logic built into popHealth v1.4 for the Meaningful Use Stage 1 CQM, NQF 0421 Adult Weight Screening:

function() {
var patient = this;
var measure = patient.measures["0421"];
if (measure == null)
measure={};

var day = 24 * 60 * 60;
var year = 365 * day;
var effective_date = <%= effective_date %>;

var measurement_period_start = effective_date - (1 * year);
var latest_birthdate = latestBirthdayForThisAge(65, measurement_period_start);
var earliest_encounter = measurement_period_start - year;

var population = function() {
var correct_age = patient.birthdate <= latest_birthdate;
return (correct_age);
}

var denominator = function() {
return inRange(measure.encounter_outpatient_encounter,
earliest_encounter, effective_date);
}

var numerator = function() {
return weight_numerator(measure, 22, 30);
}

var exclusion = function() {
return weight_exclusion(measure, earliest_encounter, effective_date);
}

map(patient, population, denominator, numerator, exclusion);
};

By having a single procedural definition for both CQMs and CDS, we should be able to have a higher level of confidence in the performance of the EHR systems that have to implement either a CQM or CDS. What could then be done, is test and certify EHR systems ability to process the procedural definition of the standard, and then have a higher level of confidence that the any new CQM expressed in procedural logic... as long as it were syntactically well formed... would work with an EHR system.

The benefit to this type of approach is accelerated velocity in development, testing, and deployment of new CQMs and new CDS reports/rules.

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

The Four Different Types of Clinical Quality Measures

2013-06-04T10:26:00.002-04:00

Clinical Quality Measures (CQMs) have been a significant part of my work for the past 3 years. My first foray into the CQM space was with the popHealth project, which is a reference implementation of the CQM logic that a provider or EHR vendor could use or incorporate into a software project. popHealth was entirely focused on a family of CQMs called "proportion-based".

While the "proportion-based" CQMs get the majority of the attention with the healthcare community, it was not until a year working on popHealth that I discovered that there are a total of four different types of CQMs that affect how the CQM logic is implemented and reported.

The four different classifications of CQM logic are:

Proportion

This is the type of CQM that most individuals are familiar with when referring to the Meaningful Use program.
These types of CQMs are routinely referred to as the "Numerator/Denominator" CQMs. I recently wrote about the exception and exclusion logic, but it is worth noting that those CQM reporting characteristics are only applied to proportion-based CQMs.
Usually, the proportion-based CQMs are a positive measurement of quality, meaning that usually, the higher the value of the Numerator/Denominator proportion, the better you are doing as a healthcare provider
Example: "What percentage of women over the age of 45 and under the age of 65, who have had an outpatient encounter in the past 2 years, have had a mammography screening?"

Continuous Variable

These CQMs are usually applied in the hospital CQM domain.
These types of CQMs measure the average time
Example: "What is the average time for Emergency Department (ED) admission until either Discharge or Admission to Inpatient Hospitalization?"

Episode of Care

These CQMs assess each distinct ‘encounter’ between a patient and a provider, during a a measurement period.
A single patient can contribute to numerous considerations of the CQM result if they had numerous encounters
Examples: "Did the provider measure the patient’s blood pressure during a particular episode?" or "Were heart attack patients discharged with an Rx for Aspirin during a particular episode?"

Longitudinal

These CQMs take into account complete patient record with focus on a ‘measurement period’
Examples: "Have patients who turned 2 years old during the measurement period received all required vaccinations on schedule?" or "Have diabetic patients received 2 foot exams during the measurement period?"

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

Meaningful Use Stage 2 XML Standards for Clinical Quality Measure Reporting

2013-05-24T16:13:00.000-04:00

When implementing an EHR system, or EHR module, that supports the Meaningful Use Stage 2 program for Clinical Quality Measure (CQM) support, there are three HL7 XML standards that you need to be aware of:

HQMF
QRDA Category 1
QRDA Category 3

The HQMF XML standard defines the data elements referenced by the logic, and associates them to value sets using object identifiers (OIDs). For those really interested in using the HQMF, you can download the HQMF files for all the Meaningful Use Stage 2 Clinical Quality Measures from the CMS site here.

The QRDA Category 1 XML standard is what is used for expressing patient-level data as inputs to a Clinical Quality Measure calculator, such as popHealth, as part of the Meaningful Use Stage 2 program. This XML standard allows for EHRs to express the clinical results of individual patients based on the CQM that an EHR system was queried about. The reports that determine the data to include in the QRDA Category 1 XML are tightly coupled to the HQMF definition of the measure. I have shared high-level information about the QRDA Category 1 specification, as well as an example of what the QRDA Category 1 XML should look like.

Lastly, the QRDA Category 3 XML standard is what is used to express the summary results of a CQM. It is unfortunate that the QRDA Category 1 and Category 3 are worded so similarly, yet have significantly different roles in this landscape. The QRDA Category 3 is the artifact that needs to be generated for expressing summary/aggregate report numbers. For instance, if the CQM report where created to assess the mammography screening results of women between the ages of 45 and 65 years old, and the result were 73% of that population met that criteria, the QRDA Category 3 XML could express the 73% performance rate, as well as counts associated with the initial patient population, the denominator, the numerator , the exception, and exclusion populations. You can view an illustration of these different CQM logical families for the proportion-based CQMs here.

Below is an illustration that details the use of these various HL7 XML standards when reporting on Meaningful Use Stage 2 Clinical Quality Measures.

Landscape of Meaningful Use Stage 2 Clinical Quality Measure XML Standards

Hopefully this is helpful. If not, let me know!

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

Designing Logos for a Portfolio of Healthcare Projects

2013-05-17T14:30:00.001-04:00

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.

Remaining "Agile" with a Medium-Sized Team

2013-05-11T11:27:00.007-04:00

I am hoping to start leading a new (really old... but soon-to-be revived) open source health IT project very soon. The good news is that it's appearing that the project will be well-supported, and that we will be able to staff the project team up to a very good size. I'm also planning on continuing to embrace an agile project management process using scrum.

One of the key benefits to having a successful agile process has been the shared situational awareness of the members of the project which allows the team to self-organize. If I am needed less on the small but blocking minute-to-minute decision making, there's a higher probability of exceeding the expected outcomes of our sponsor while simultaneously growing new leaders for the future. Additionally, I am happy to perform less tactical work and focus more on strategy.

With the right project team (talented... responsible... multi-domain... passionate) it is remarkably easy to be successful on any project; from a project that is technology-heavy software development activity, to one that is primary focused on steering or influencing federal policy.

After originally being a software engineer, have been leading software projects for about 7 years, and my largest projects have been right around 5-8 Full Time Equivalent (FTE). I am now facing the prospect of leading a 14 FTE project... this is a first for me.

One concern of leading a project of this size is the increasing number of individual communication links that would be needed for everyone on the team to know what everyone else on the team is working on to maintain shared situational awareness on the project.

To illustrate this, you can see how the communication links will continue to increase non-linearly with more and more staff. L = number of communication links, T = number of members of the team.

Additionally about half of the 14 Full Time Equivalent (FTE) project team are co-located in an agile bullpen room, while the other half are geographically distributed across the East Coast... from Massachusetts, New Jersey, Virginia, all the way down to Florida. The good news with this distributed team is that the entire roster will be based in Eastern Standard Time. At least we will not be depriving individuals of sleep with meetings that span numerous time zones!

My thoughts of dealing with this if/when this new project starts, and try the Scum Alliance model of hosting a "Scrum of Scrums". My current plan is to have co-located team maintain their agile "bullpen" and have one scrum, and have the geographically-distributed team scrum either after or before them. The two team would have a size of approximately 7 FTE each. They should both be able to maintain a cross-domain roster of engineers, healthcare informaticists, clinicians, policy leaders, and Clinical Quality Measure SMEs.

To follow the "Scrum of Scrums" process, I plan to identify a scrum master from each team, and after the daily scrums, the scrum masters, product owner and stakeholders will host a second scrum. Again following the Scrum Alliance variant on the "Scrum of Scrums" meeting, the agenda for that meeting will deviate a little by addressing the following questions:

Because the "Scrum of Scrums" meetings may not be daily and because one person is there representing his or her entire team, these three questions need to be rephrased a bit to be "team-focused" and they suggest it's beneficial to add a fourth question, identifying if the two teams might be unintentionally stepping on each others' toes:

What has each team done since yesterday?
What will each team do today?
Are there any impediments to the team's plan today?
Are you about to put something in the other team’s way?

It looks good and makes sense. I hope to report out on how this "Scrum of Scrums" works.

Fingers crossed...

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

Meaningful Use Stage 2 Exception vs. Exclusion Logic Explained

2013-05-06T12:37:00.004-04:00

Introduced in Meaningful Use Stage 2 was the notion of both exception logic and exclusion logic with the Proportion-Based CQMs. Based on numerous conversations over the past several months, there appears to be ongoing confusion in logical implementation of exception and exclusion logic for these CQMs as part of the Meaningful Use program.

The authoritative resource for this explanation is the Clinical Quality eMeasure Logic and Implementation Guidance Document that is publicly available on the CMS site. The details for proportion-based CQM that I have paraphrased follows below:

Initial Patient Population: The set of patients (or episodes of care) to be evaluated by the measure.
Denominator Population: A subset of the Initial Patient Population.
Exclusion Population: The members of the Denominator that should not be considered for inclusion in the Numerator.
Numerator Population: A subset of the Denominator. The numerator criteria are the processes or outcomes expected for each patient, procedure, or other unit of measurement defined in the denominator.
Exception Population: These are the members of the Denominator that were considered for membership in the Numerator, but were rejected, and meet the logic required for the exception criteria.

I have included an illustration that attempts to capture this updated logic for Meaningful Use Stage 2.

Meaningful Use Stage 2 Proportion-Based CQM Logic

These final population counts are then used to calculate the performance rate of any CQM against a population of patients via the following formula:

Performance Rate = Numerator Count / (Denominator Count – Exclusion Count – Exception Count)

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

Example QRDA Category 1 XML for Meaningful Use Stage 2 Clinical Quality Measure Reporting

2013-04-27T11:29:00.006-04:00

Last fall, I wrote about the QRDA Category 1 XML Standard as a way of expressing inputs to Clinical Quality Measures for the Meaningful Use Stage 2 program. More recently, I have become immersed in the QRDA Category 1 while leading the open source Cypress project for the Office of the National Coordinator of Health Information Technology (ONC) and the Meaningful Use Stage 2 CQM Testing and Certification Program.

Under ONC, the Meaningful Use Program tests and certifies EHR technologies as part of the Meaningful Use Program via Authorized Testing Laboratories (ATLs), who are the organizations that use the tools and policies identified by ONC. The Cypress project is the authoritative testing and certification tool used for the MU Stage 2 Clinical Quality Measures, and includes testing for the QRDA Category 1 XML specification.

Based on all the work our team has been supporting with the QRDA Category 1 XML, I thought it would be helpful to demonstrate how a CQM can define the data that would need to be expressed in a QRDA Category 1 XML file.

As an example, I am selecting NQF 0018 "Controlling High Blood Pressure", which measures the percentage of patients, aged 18-85 years old at the time of the CQM's measurement, and who had some sequence of encounters with a provider, and a diagnosis of hypertension, and whose blood pressure was adequately controlled (<140/90mmHg) during the measurement period.

If you wanted to see the full logic of this particular CQM, the visualization that is automatically generated from the open source popHealth project that I am leading is below:

Denominator Logic

individual characteristicbirth date

>= 18 years starts before start of measure period

and

individual characteristicbirth date

<= 85 years starts before start of measure period

and

diagnosis condition problemessential hypertension

<= 6 months starts after start of measure period

diagnosis condition problemessential hypertension

starts before start of measure period

and

encounteroffice visit

during measure period

encounterface-to-face interaction

during measure period

encounterpreventive care services - established office visit, 18 and up

during measure period

encounterpreventive care services-initial office visit, 18 and up

during measure period

encounterhome healthcare services

during measure period

encounterannual wellness visit

during measure period

Numerator Logic

physical examdiastolic blood pressure < 90 mm Hg

duringrecent of

encounteroffice visit

during measure period

encounteroutpatient consultation

during measure period

encounterpreventive care services-initial office visit, 18 and up

during measure period

encounterpreventive care services - established office visit, 18 and up

during measure period

encounterface-to-face interaction

during measure period

encounterhome healthcare services

during measure period

encounterannual wellness visit

during measure period

and

physical examsystolic blood pressure < 130 mm Hg

duringrecent of

encounteroffice visit

during measure period

encounteroutpatient consultation

during measure period

encounterpreventive care services-initial office visit, 18 and up

during measure period

encounterpreventive care services - established office visit, 18 and up

during measure period

encounterface-to-face interaction

during measure period

encounterhome healthcare services

during measure period

encounterannual wellness visit

during measure period

Consider some realistic but minimal health data applied against that particular CQM and let's see what what a QRDA Category 1 XML file for me would look like. Assume I have the following notional clinical data assigned to me in an Electronic Health Record system:

First Name: John
Last Name: Doe
DoB: June 24, 1975
Address: 123 Main Street Gardner, MA 01440
Work phone: 781-271-7102
HL7 Gender: Male
Spoken Language: English
CDC Race: White
CDC Ethnicity: Not Hispanic or Latino
Conditions: Hypertension diagnosed on March 1st, 2012
Encounters: Office Visit on March 1st, 2012
Office Visit on July 1st, 2012
Blood Pressure Visit on November 1st, 2012
Systolic BP: 127 mmHg on March 1st, 2012
123 mmHg on November 1st, 2012
Diastolic BP: 79 mmHg on March 1st, 2012
81 mmHg on November 1st, 2012

Now, lets see how that clinical data for this patient should be expressed in the (very verbose) QRDA Category 1 XML format. As an FYI for how the QRDA Category 1 XML specification works, the data expressed in the QRDA Category 1 XML is in response to a CQM request.

Assume that the QRDA Category 1 XML below were generate for that particular CQM NQF 0018 "Controlling High Blood Pressure" for the Meaningful Use Stage 2 program. Also, assume a reporting period ending on December 31st, 2012 23:59. I am highlighting in yellow within the XML below where the clinical data that I enumerated for our notional patient is expressed in the QRDA Category 1 XML:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="cda.xsl"?>
<ClinicalDocument xmlns="urn:hl7-org:v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:voc="urn:hl7-org:v3/voc"
xmlns:sdtc="urn:hl7-org:sdtc">
<realmCode code="US"/>

<templateId root="2.16.840.1.113883.10.20.22.1.1"/>
<templateId root="2.16.840.1.113883.10.20.24.1.1"/>
<templateId root="2.16.840.1.113883.10.20.24.1.2"/>
<id root="5b010313-eff2-432c-9909-6193d8416fac"/>
<code code="55182-0"
codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC"
displayName="Quality Measure Report"/>
<title>QRDA Report for John Doe</title>
<effectiveTime value="20130427145038"/>
<confidentialityCode code="N"
codeSystem="2.16.840.1.113883.5.25"/>
<languageCode code="eng"/>
<recordTarget>
<patientRole>
<id extension="12345" root="2.16.840.1.113883.4.572"/>
<addr use="HP">
<streetAddressLine>123 Main Street</streetAddressLine>
<city>Gardner</city>
<state>MA</state>
<postalCode>01440</postalCode>
<country>US</country>
</addr>
<telecom use="WP" value="tel:+1-781-271-7102"/>
<patient>
<name>
<given>John</given>
<family>Doe</family>
</name>
<administrativeGenderCode code="M"
codeSystem="2.16.840.1.113883.5.1"
codeSystemName="HL7 AdministrativeGender"/>
<birthTime value="19750624120000"/>
<raceCode code="2106-3"
displayName="White"
codeSystemName="CDC Race and Ethnicity"
codeSystem="2.16.840.1.113883.6.238"/>
<ethnicGroupCode code="2186-5"
displayName="Not Hispanic or Latino"
codeSystemName="CDC Race and Ethnicity"
codeSystem="2.16.840.1.113883.6.238"/>
<languageCommunication>
<templateId root="2.16.840.1.113883.3.88.11.83.2"
assigningAuthorityName="HITSP/C83"/>
<templateId root="1.3.6.1.4.1.19376.1.5.3.1.2.1"
assigningAuthorityName="IHE/PCC"/>
<languageCode code="eng"/>
</languageCommunication>
</patient>
</patientRole>
</recordTarget>
<author>
<time value="20130427145038"/>
<assignedAuthor>
<id extension="FakeNPI" root="2.16.840.1.113883.4.6"/>
<addr>
<streetAddressLine>234 Main Street</streetAddressLine>
<city>Gardner</city>
<state>MA</state>
<postalCode>01440</postalCode>
<country>US</country>
</addr>
<telecom use="WP" value="tel:(781)271-7102"/>
<assignedAuthoringDevice>
<manufacturerModelName>AcmeEHR</manufacturerModelName>
<softwareName>AcmeEHR</softwareName>
</assignedAuthoringDevice>
</assignedAuthor>
</author>
<custodian>
<assignedCustodian>
<representedCustodianOrganization>
<id root="2.16.840.1.113883.19.5"/>
<name>Fake Custodian</name>
<telecom use="WP" value="tel:(781)555-5555"/>
<addr>
<streetAddressLine>345 Main Street</streetAddressLine>
<city>Gardner</city>
<state>MA</state>
<postalCode>01440</postalCode>
<country>US</country>
</addr>
</representedCustodianOrganization>
</assignedCustodian>
</custodian>
<legalAuthenticator>
<time value="20130427145038"/>
<signatureCode code="S"/>
<assignedEntity>
<id root="bc01a5d1-3a34-4286-82cc-43eb04c972a7"/>
<addr>
<streetAddressLine>567 Main Street</streetAddressLine>
<city>Gardner</city>
<state>MA</state>
<postalCode>01440</postalCode>
<country>US</country>
</addr>
<telecom use="WP" value="tel:(781)271-3000"/>
<assignedPerson>
<name>
<given>Mike</given>
<family>Doe</family>
</name>
</assignedPerson>
<representedOrganization>
<id root="2.16.840.1.113883.19.5"/>
<name>AcmeEHR</name>
</representedOrganization>
</assignedEntity>
</legalAuthenticator>
<documentationOf typeCode="DOC">
<serviceEvent classCode="PCPR">
<effectiveTime>
<low value="20100601"/>
<high value="20100915"/>
</effectiveTime>
<performer typeCode="PRF">
<time>
<low value="20020716"/>
<high value="20070915"/>
</time>
<assignedEntity>
<id root="2.16.840.1.113883.4.6" extension="111111111"/>
<representedOrganization>
<id root="2.16.840.1.113883.4.2" extension="1234567"/>
<id root="2.16.840.1.113883.4.336" extension="54321"/>
</representedOrganization>
</assignedEntity>
</performer>
</serviceEvent>
</documentationOf>
<component>
<structuredBody>
<component>
<section>
<templateId root="2.16.840.1.113883.10.20.24.2.2"/>
<templateId root="2.16.840.1.113883.10.20.24.2.3"/>
<code code="55186-1" codeSystem="2.16.840.1.113883.6.1"/>
<title>Measure Section</title>
<text>
<table border="1" width="100%">
<thead>
<tr>
<th>eMeasure Title</th>
<th>Version neutral identifier</th>
<th>eMeasure Version Number</th>
<th>NQF eMeasure Number</th>
<th>Version specific identifier</th>
</tr>
</thead>
<tbody>
<tr>
<td>Controlling High Blood Pressure</td>
<td>ABDC37CC-BAC6-4156-9B91-D1BE2C8B7268</td>
<td>1</td>
<td>5177f5798538a2f952caf324</td>
<td>8A4D92B2-397A-48D2-0139-C6208B875109</td>
<td/>
</tr>
</tbody>
</table>
</text>
<entry>
<organizer classCode="CLUSTER" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.24.3.98"/>

<templateId root="2.16.840.1.113883.10.20.24.3.97"/>
<statusCode code="completed"/>
<reference typeCode="REFR">
<externalDocument classCode="DOC" moodCode="EVN">
<id root="8A4D92B2-397A-48D2-0139-C6208B875109"/>
<text>Controlling High Blood Pressure</text>
<setId root="ABDC37CC-BAC6-4156-9B91-D1BE2C8B7268"/>
<versionNumber value="1"/>
</externalDocument>
</reference>
</organizer>
</entry>
</section>
</component>
<component>
<section>
<templateId root="2.16.840.1.113883.10.20.17.2.1"/>
<code code="55187-9" codeSystem="2.16.840.1.113883.6.1"/>
<title>Reporting Parameters</title>
<text>
<list>
<item>Reporting period: January 1st, 2012 -
December 31st, 2012</item>
</list>
</text>
<entry typeCode="DRIV">
<act classCode="ACT" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.17.3.8"/>
<code code="252116004"
codeSystem="2.16.840.1.113883.6.96"
displayName="Observation Parameters"/>
<effectiveTime>
<low value="20120101000000"/>
<high value="20121231235900"/>
</effectiveTime>
</act>
</entry>
</section>
</component>
<component>
<section>
<templateId root="2.16.840.1.113883.10.20.17.2.4"/>
<templateId root="2.16.840.1.113883.10.20.24.2.1"/>
<code code="55188-7" codeSystem="2.16.840.1.113883.6.1"/>
<title>Patient Data</title>
<text/>
<entry>
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.2"/>
<templateId root="2.16.840.1.113883.10.20.24.3.57"/>
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce61000287"/>
<code code="8462-4"
codeSystem="2.16.840.1.113883.6.1"
sdtc:valueSet="2.16.840.1.113883.3.526.3.1033">
<originalText>Physical Exam, Finding:
Diastolic BP</originalText>
</code>
<statusCode code="completed"/>
<effectiveTime>
<low value="20120301120000"/>
<high value="20120301120000"/>
</effectiveTime>
<value xsi:type="PQ" value="79" unit="mmHg"/>
</observation>
</entry>
<entry>
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.2"/>
<templateId root="2.16.840.1.113883.10.20.24.3.57"/>
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce6100028d"/>
<code code="8462-4"
codeSystem="2.16.840.1.113883.6.1"
sdtc:valueSet="2.16.840.1.113883.3.526.3.1033">
<originalText>Physical Exam, Finding:
Diastolic BP</originalText>
</code>
<statusCode code="completed"/>
<effectiveTime>
<low value="20121101120000"/>
<high value="20121101120000"/>
</effectiveTime>
<value xsi:type="PQ" value="81" unit="mmHg"/>
</observation>
</entry>
<entry>
<encounter classCode="ENC" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.49"/>
<templateId root="2.16.840.1.113883.10.20.24.3.23"/>
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce6100027f"/>
<code code="99201"
codeSystem="2.16.840.1.113883.6.12"
sdtc:valueSet="2.16.840.1.113883.3.464.1003.101.12.1001">
<originalText>Encounter, Performed:
Office Visit</originalText>
</code>
<text>Encounter, Performed:
Office Visit</text>
<statusCode code="completed"/>
<effectiveTime>
<low value="20120301120000"/>
<high value="20120301130000"/>
</effectiveTime>
</encounter>
</entry>
<entry>
<encounter classCode="ENC" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.49"/>
<templateId root="2.16.840.1.113883.10.20.24.3.23"/>
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce61000280"/>
<code code="99201"
codeSystem="2.16.840.1.113883.6.12"
sdtc:valueSet="2.16.840.1.113883.3.464.1003.101.12.1001">
<originalText>Encounter, Performed:
Office Visit</originalText>
</code>
<text>Encounter, Performed:
Office Visit</text>
<statusCode code="completed"/>
<effectiveTime>
<low value="20120701120000"/>
<high value="20120701130000"/>
</effectiveTime>
</encounter>
</entry>
<entry>
<encounter classCode="ENC" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.49" />
<templateId root="2.16.840.1.113883.10.20.24.3.23" />
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce61000281"/>
<code code="185349003"
codeSystem="2.16.840.1.113883.6.96"
sdtc:valueSet="2.16.840.1.113883.3.464.1003.101.12.1001">
<originalText>Encounter, Performed:
Blood Pressure Visit</originalText>
<translation code="99202" codeSystem="2.16.840.1.113883.6.12"/>
</code>
<text>Encounter, Performed:
Blood Pressure Visit</text>
<statusCode code="completed"/>
<effectiveTime>
<low value="20121101120000"/>
<high value="20121101130000"/>
</effectiveTime>
</encounter>
</entry>
<entry>
<encounter classCode="ENC" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.49" />
<templateId root="2.16.840.1.113883.10.20.24.3.23" />
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce61000281" />
<code code="185349003"
codeSystem="2.16.840.1.113883.6.96"
sdtc:valueSet="2.16.840.1.113883.3.464.1003.101.12.1048">
<originalText>Encounter, Performed:
Blood Pressure Visit</originalText>
<translation code="99202"
codeSystem="2.16.840.1.113883.6.12"/>
</code>
<text>Encounter, Performed:
Blood Pressure Visit</text>
<statusCode code="completed" />
<effectiveTime>
<low value="20121101120000" />
<high value="20121101130000" />
</effectiveTime>
</encounter>
</entry>
<entry>
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.2" />
<templateId root="2.16.840.1.113883.10.20.24.3.57" />
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce61000285" />
<code code="8480-6"
codeSystem="2.16.840.1.113883.6.1"
sdtc:valueSet="2.16.840.1.113883.3.526.3.1032">
<originalText>Physical Exam, Finding:
Systolic Blood Pressure</originalText>
</code>
<statusCode code="completed"/>
<effectiveTime>
<low value="20120301120500"/>
<high value="20120301120500"/>
</effectiveTime>
<value xsi:type="PQ" value="127" unit="mmHg"/>
</observation>
</entry>
<entry>
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.2" />
<templateId root="2.16.840.1.113883.10.20.24.3.57" />
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce6100028b" />
<code code="8480-6"
codeSystem="2.16.840.1.113883.6.1"
sdtc:valueSet="2.16.840.1.113883.3.526.3.1032">
<originalText>Physical Exam, Finding:
Systolic Blood Pressure</originalText>
</code>
<statusCode code="completed"/>
<effectiveTime>
<low value="20121101120000"/>
<high value="20121101120000"/>
</effectiveTime>
<value xsi:type="PQ" value="123" unit="mmHg"/>
</observation>
</entry>
<entry>
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.4" />
<templateId root="2.16.840.1.113883.10.20.24.3.11" />
<id root="1.3.6.1.4.1.115"
extension="5177f5807938a7ce6100027e"/>
<code code="282291009"
displayName="diagnosis"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED-CT"/>
<text>Diagnosis, Active: Hypertension</text>
<statusCode code="completed"/>
<effectiveTime>
<low value="20120301123000"/>
<high nullFlavor="UNK"/>
</effectiveTime>
<value code="10725009"
codeSystem="2.16.840.1.113883.6.96"
xsi:type="CD"
sdtc:valueSet="2.16.840.1.113883.3.464.1003.104.12.1011">
<originalText>Diagnosis, Active: Hypertension</originalText>
<translation code="401.1"
codeSystem="2.16.840.1.113883.6.103"/>
</value>
<entryRelationship typeCode="REFR">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.6"/>
<templateId root="2.16.840.1.113883.10.20.24.3.94"/>
<id root="da6b50c0-9177-0130-01b7-12313d02bdec" />
<code code="33999-4"
codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="status" />
<statusCode code="completed"/>
<value xsi:type="CD"
code="55561003"
displayName="active"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"/>
</observation>
</entryRelationship>
</observation>
</entry>
</section>
</component>
</structuredBody>
</component>
</ClinicalDocument>

If your first impression that this is bloated XML... you are not alone.

The primary cause of this "bloat" really traces its routes back to the HL7 Clinical Document Architecture and the HL7 RIM for expressing effectively anything (from individual patient records to Clinical Quality Measure procedural logic!) in XML. However, as much as I hate HL7 XML-based documents, there is a little bit of goodness with respect to the QRDA Category 1 XML for expressing patient-level data as inputs to Clinical Quality Measures.

Several HL7 standards have proven to demonstrate failures as inputs to Clinical Quality Measures; the HL7 Continuity of Care Document (CCD), the HITSP C32, or the Consolidated CDA. These are all general XML standards meant for expressing patient-level data for continuity of care from one provider to another via an XML format.

The silver lining on the QRDA Category 1 cloud is that once the clinical data that is needed for a particular CQM has been identified in an EHR system, the way to express that clinical data on a patient-by-patient basis is clear(er) and more tractable for systems that will need to parse and interoperate with the structured data.

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

Complexity Analysis of MU Stage 2 Eligible Professional Clinical Quality Measures

2013-02-05T09:26:00.000-05:00

I recently wrote about the initial release of the MITRE open source Kamira project to assess the quality of Clinical Quality Measures (CQMs). The initial focus of the Kamira project has been the Cyclomatic Complexity analysis of the CQM logic.

The Kamira project has listened to my evangelizing the use of Kiviat charts as the visualization technique used with CQMs. In addition to being fairly useful for understanding the CQM complexity results, I have found that the Kiviat visualizations also have a "sexiness" factor that I have been leveraging to continue the research. See the Kamira Cyclomatic Complexity dashboard design below:

Kamira complexity dashboard design

What we did with the Kiviat visualization for the complexity results is leverage the five attributes that could always be used for parts of the CQM algorithmic logic:

Initial Patient Population (IPP)
Denominator
Numerator
Exclusion
Exception

We then associated ranges for the complexity metrics based on the Carnegie Mellon University paper that I identified a few months ago. These ranges are:

1-10: Very Simple, Low Risk (green)
11-20: Nominal, Moderate Risk (yellow)
21-50: Complex, High Risk (orange)
>50: Untestable, Extreme Risk (red)

Since we wanted to highlight the worst/highest component of the CQM, we opted to color in the area of the five metrics with the worst/highest section of the algorithmic logic.

Because some of the MU Stage 2 CQM logical sections far exceeded CMU's threshold of 50 for "Untestable, Extreme Risk" we found that there were some CQMs that had logical sections that were "off the scale" when it came to Cyclomatic Complexity. The worst violator is "NQF 0038: Childhood Immunizations" which is actually part of the core set of MU Stage 2 for Eligible Professional CQMs.

Since we couldn't use a linear scale for those CQMs, so we capped the scale at 60, and switched the presentation of the results around by providing a red background around the Cyclomatic Complexity value. Normally, there isn't a background and the results are just black text. The idea here was to try and call out that there was something fundamentally wrong with complexity values that are so high.

See the 6 most complex CQMs for MU Stage 2 Eligible Professionals (EP) below:

6 Most Complex CQMs for MU Stage 2 Eligible Professionals

From a software engineer's perspective, if you have to manually implement these CQMs in software code, you are going to be very hard pressed to test and validate that any system implementing this logic accurately. Ie. you have a challenging job ahead of you to test that any implementation of these 6 CQMs are in fact accurate. This also means that there's a higher probability of having a lurking software bug in your implementation.

Also, for healthcare providers who need to understand these CQMs in order to improve the quality of care that they are providing to their patients, they will also have a challenge. Providers needing to maintain a mental model of the CQMs and understand what actions should be taken for their patients will likely face challenges.

Ideally, the complexity of the CQMs should never even get this high. What I would want to see is some consideration by measure stewards on Cyclomatic Complexity during the development process. Another consideration for the policy leaders would be refusal to accept any CQM submitted that had a Cyclomatic Complexity value that exceeded a threshold.

The Kamira project's work has initially focused on the Meaningful Use Stage 2 Eligible Professional CQMs. The reason that these were initially selected is because we were easily able to instrument the JavaScript code that is implemented in the popHealth and Cypress project's quality measure engine. However, the work can be expanded to include the MU Stage 2 Eligible Hospital (EH) CQMs when those are implemented in popHealth and Cypress, currently planned for late April 2013. Unfortunately, I expect that the EH CQMs will actually be more complex than the EP CQMs.

Additionally, I have plans to expand the work into financial analysis and feasibility of implementing CQMs, but for now the lowest hanging fruit was the complexity analysis.

The full visualization of the Meaningful Use Stage 2 CQM Complexity Data is available here, and the detailed results in a JSON file is available here.

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

Complexity and Certification of MU Stage 1 Eligible Professional Clinical Quality Measures

2013-02-03T20:02:00.000-05:00

While working in the Clinical Quality Measure space on the two open source projects popHealth and Cypress, I have observed trends in the adoption of EHR vendors of various Clinical Quality Measures (CQMs). For a little background on the role of CQMs in the Meaningful Use program, read the beginning of the entry that I wrote about Applying Kiviat Visualization to Meaningful Use Clinical Quality Measures.

For Meaningful Use Stage 1, there are minimal requirements by EHR vendors to support the 6 Core and Core Alternate CQMs, and any 3 of the remaining 38 Meaningful Use Stage 1 CMS. This allows for some malleability by the commercial EHR vendors to select CQMs based on either their ability to implement CQM logic in their product or based on customer demand for specific CQMs.

The Office of the National Coordinator for Health Information Technology (ONC) hosts the Certified HealthIT Product List (CHPL pronounced "CHaPeL") service. You can view the list of certified products through the CHPL web interface. Compiling the results for the EHR products against various Meaningful Use Stage 1 CQMs, there are some interesting results:

Meaningful Use Stage 1 Ambulatory Clinical Quality Measures:
Adoption by EHR vendors from data collected via the CHPL service

In addition to the work I am leading via Cypress, I am also leading a research project to assess the quality of Clinical Quality Measures called "Kamira". The Kamira project can provide metrics on the quality of CQMs. For early 2013, this has included automated Cyclomatic Complexity calculation of the CQM algorithmic logic based off of the JavaScript code that the Cypress and popHealth projects use to calculate the CQM results.

If you then compare the results of the CQMs that were tested and certified by EHR vendors against the complexity score of the CQMs, you can see a weak correlation between the two. You can download the full file with the results here.

Meaningful Use Stage 1 Ambulatory Clinical Quality Measures:
Adoption by EHR vendors from data collected via the CHPL service
compared against Cyclomatic Complexity Analysis of the CMQ logic

It's worth noting that the correlation here is weak, but there does appear to be a trend toward vendors opting to implement the less complex CQMs in their products when they have some latitude to choose.

FYI, the ranges for the CQM complexity (the colored diamonds) are:

1-10 Very Simple/Low Risk (green)
11-20 Nominal/Moderate Risk (yellow)
21-50 Complex/High Risk (orange)
>50 Untestable/Extreme Risk (red)

These metrics are somewhat arbitrary, but I picked ranges for CQM complexity from a Carnegie Mellon paper that had a good number of citations, so I think that the values and thresholds are fairly defensible.

Where this work might have a few vulnerabilities is that I am 100% certain that EHR vendors do not use complexity as their only consideration when selecting CQMs to implement in their products. For instance some of the red, highly complex CQMs which were in the middle when it came to adoption by EHR vendors are cardiac CQMs. From my perspective, it's a safe assumption that some of these EHR vendors were going to bite bullet and implement the cardiac CQMs regardless of the complexity associated with them because there is more demand in the marketplace from providers that need the cardiac CQM results, vs. say the behavioral health CQMs. However, I think that CQM developers need to start tracking complexity of CQMs as they are developed for MU Stage 3 or beyond.

Lastly, the Kamira project just launched last week. I plan on posting the MU Stage 2 complexity results for the Eligible Professional CQMs in the coming weeks.

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

Longitudinal Visualization Techniques for Clinical Quality Measures

2012-11-25T08:44:00.001-05:00

I recently wrote about Applying Kiviat Visualization to Meaningful Use Clinical Quality Measures. One additional item that is a limitation to using Kiviat diagrams is the visualization of longitudinal trending of metrics over time. This same limitation exists with Clinical Quality Measures (CQMs).

I am a big fan of Edward Tufte, and his evangelism on the use of sparklines. Below is an interpretation of how that same sparkline visualization could be applied to a family of diabetic CQMs from the Meaningful Use program, that is a modified version of Juhan Sonin's HealthCard:

This technique does make some assumptions. It appears to look decent with two years of notional data. However, I think that changes in CQM results will probably be needed over decades. Also, I am not sure if someone like Tufte would violently object to the introduction of date under the illustration.

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

The QRDA Category 1 XML Standard

2012-10-07T18:07:00.001-04:00

The Quality Reporting Document Architecture (QRDA) Category 1 standard is a new XML standard designed for communicating patient-level clinical data that will be used to calculate Clinical Quality Measures (CQMs). This is an HL7 XML standard that is part of the Clinical Document Architecture (CDA), which is an overall framework for expressing healthcare data in XML that is also stewarded by HL7.

The QRDA Category 1 XML standard was created because systems needing to calculate Clinical Quality Measures (CMSs) could not guarantee that patient-level data would appear in the existing continuity of care standards such as the HITSP C32, HL7 Consolidated CDA (CCDA), and the ASTM Continuity of Care Record (CCR). The QRDA Category 1 standard has been designed so that all of the clinical information needed for each specific CQM will need to be expressed within the QRDA Category 1 XML document.

The QRDA Category 1 is a clinical document representing a single patient. It defines sections containing measure information and patient data that meets criteria for a measure. It also contains information on the reporting period. The markup for the patient data is the same as a CCDA document.

In a nutshell, the QRDA Category 1 XML standard will include the templates needed for each attribute in each CQM that a patient could provide clinical data to be used to calculate any number of CQMs. Additionally, more than one CQM can be included in the request for the clinical data associated with one patient.

If you view the illustration below, you can see that an Electronic Health Record (EHR) system may be requested to generate QRDA Category 1 XML for patients to be used to drive the calculation of the Diabetes Blood Pressure Management CQM AND the Diabetes LDL Test CQM. In that case, all clinical data that could be used to drive the calculation of either of those CQMs must appear in the QRDA Category 1 for each patient in the EHR. Further, additional clinical information associated with each patient is not required, and will result in warnings (but not errors) in the QRDA Category 1 for each patient.

The C32/CCDA vs QRDA Category 1
Only relevant data is expressed in the QRDA Category 1
based on the need for specific CQMs

I personally feel that the QRDA Category 1 reflects the failures of the CCR, C32, and CCDA standards. It is difficult to explain why a single standard for expressing patient-level data that is interoperable and can provide sufficient fidelity of data for calculating CQMs does still not exist. It's 2012.

Where problems are identified with a CQM when the CCR... the C32... the CCDA do not provide sufficient information for calculating MU CQMs, CQMs could be adjusted to be simpler, and conform to data that must exist in the CCR... the C32... the CCDA. This lack of a good continuity of care standard for a single patient record is what I feel is the root cause of all of this work.

Knowing that the QRDA Category 1 isn't going away anytime soon, I have found that the use of the QRDA Category 1 XML standard has been difficult due to lack of validation tests and example QRDA Category 1 XML files. However, I suspect that these two shortcomings will be addressed in time.

The objective of using the QRDA Category 1 XML standard as a mechanism to present clinical quality data associated with a patient should unambiguously define clinical attributes so that there’s no confusion about what is expected of an EHR system's ability to export in XML artifacts. Time will tell if this objective is realized in EHR systems... I remain skeptical. I think we will know a lot more by 2013, when this standard is officially introduced into the Meaningful Use Stage 2 program.

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

Review: CardioChek PA Blood Meter

2012-09-13T16:50:00.001-04:00

I have been working for the Office of the National Coordinator for Health Information Technology (ONC), on the popHealth and Cypress projects for several years now. Both projects are based around Clinical Quality Measures (CQMs).

By education, I am a physicist and engineer, and not a clinician. However, I have repeatedly noticed the importance of lipid profiles within the context of the logic of several of the Meaningful Use CQMs. Further, in the very recent past, these metrics had been considerably high for me; a male in my late 30's. Between my work looking at CQMs emphasizing the importance of just measuring lipid profiles, and my own personal warning signs associated with this health metric, I thought it would be good to collect some "hands on" experiences with the collection of the data for this metric.

When my department at MITRE had some additional overhead resources available at the end of our fiscal year, I purchased a portable blood testing device that could provide me with my own lipoid profile information (total cholesterol, HDL cholesterol, LDL cholesterol, and triglycerides).

I eventually picked the CardioChek PA blood meter device. Interestingly, this was not the first CardioChek blood device that I purchased. I originally found the consumer CardioChek (no "PA") device on Amazon.com. The consumer device lists at about $125. That seemed reasonable, but the device requires three separate strips to measure total cholesterol, HDL cholesterol, and triglycerides (you can calculate the LDL cholesterol from those three). While that may not sound bad, I quickly found out that it involved giving myself at least two, sometimes three, pricks with lancets to draw enough blood for the three separate tests.

Additionally, I purchased this device for my department at work, and felt that an experience getting three pokes with a needle might not go over well with my colleagues, resulting in some future retribution via office pranks.

To solve the problem of collecting a full lipoid panel from one drop of blood, I purchased these PTS panels that appeared nice in the sense that they have the ability to drive the calculation of multiple readings from a single sample of blood.

Each box comes with one lipid panel MEMo chip that can be inserted
into a CardioChek PA device and 15 single use lipid profile panels

Unfortunately, I quickly discovered that these really nice 3-in-1 lipid profile panels are not compatible with the $125 consumer CardioChek device. To support multiple readings from a single drop of blood would require the more expense CardioChek PA device, that runs at close to $700.

Being the end of the fiscal year, the additional money was a little easy to come by. I went back to our finance staff and purchased the more expensive, clinical-grade device. I also picked up some supporting medical equipment like gloves, lancets, pipettes, and band aids.

CardioChek PA blood testing device, several tests
with some additional medical equipment

To take your lipid profile, you need one lipid panel test chip, called a MEMo Chip by the manufacturer, and one lipid panel test strip. The MEMo chip contains lot-specific calibration and other information needed to properly perform testing. The lot-specific information is presumably associated with the 15 test panels that come with the package. I would not recommend mixing and matching test panels with different MEMo chips, because of this prior calibration by the manufacturer.

There is also guidance around always storing the unused test panels at a temperature between 68-80˚F. I could see this temperature requirement as a challenge for some home/consumer users. Lastly, there is an expiration date on the test panels. For all the tests I have, the expiration date, is less than one year from now, a little under 8 months of viable shelf time.

You can see the relative size of the test panel and MEMo chip in the picture below. You only need one strip for a test. I just flipped one test strip over to show the single wide channel where you deposit your blood, and the three openings for the device sensor to read the total cholesterol, HDL cholesterol, and triglycerides.

Lipoid panel test chip and two lipoid panel test strips

It appears that the CardioChek PA device has the ability to independently test up to four different metrics from the single sample of blood. While I haven't found any tests that use a full four metrics from one sample, I am still happy that the manufacturer (presumably) recognized this need for multiple tests from a single sample.

CardioChek PA sensor

Collecting and depositing your sample for the device is relatively easy for an individual, non-clinician. I suggest you get 2 paper towels, and a small band aid before you get started. If you are unfamiliar with using lancets, they are small and cheap medical implements used for capillary blood sampling (no vein or arties). A lancet includes a spring-loaded needle. When used, it pops out and makes a very small puncture in your skin, allowing a few drops of blood to appear on your skin over the next ~10 seconds. They are single use and disposable.

You can see how they are fairly straight-forward to use for the blood sampling that you can then collect with pipettes.

Lancet

About one drop of blood after lancet met my finger
with small pipette in background

After my first two attempts to use the device for a full lipid profile, the device would eventually display "TEST ERROR" on the screen. Needless to say, I was disappointed to think that I had put over $1K into this exercise, and had no data to show. As it turns out, my finger was not providing enough blood to generate the full lipid profile. There is some documentation provided with the device that makes this association from the "TEST ERROR" message. However, I just can't understand why the manufacturer didn't make this more intuitive for users.

On my third attempt, when I applied a liberal amount of blood on the sample channel, the device worked fine. I feel that the accuracy of the device is very high. The readings it provided were all within 10% of measurements that I had collected from my Primary Care Provider (PCP) the previous week. For me, the time between depositing your blood on the strip until the results are displayed ranged from 40 to around 60 seconds on three test runs.

This problem that resulted in multiple "pokes" with the lancet makes for an amusing story at my expense. However, I can't emphasize enough; the "TEST ERROR" message really means "Not enough blood". This is an opportunity for improvement in this product for first time users.

On this topic of human-computer interaction, I was also disappointed with the CardioChek PA user interface. For $700, the interface feels like bleeding-edge late 1980s technology.

CardioChek PA user interface

For a $700 device, I would think that the manufacturer could easily upgrade the resolution and include color at a modest increase in manufacturing costs. Ideally, this would include some longitudinal data on changes associated with the data. See my suggested illustration below, again based on Juhan Sonin's designs for a HealthCard for the patient (consumer).

My updated lipid profile with sparkline visualizations

On the positive side, the CardioCheck PA is worth purchasing if you think you will be frequently taking your lipid profile at home. It appears very accurate on the measurement results. Once you learn the interface and how to correctly provide enough of a blood sample, the device works well.

My biggest issue with this product is the variance in the cost of the CardioChek PA device at $700, versus a slightly more limited consumer CardioChek device at $125. I feel that this price point makes the CardioChek cost-prohibitive for most consumers (patients).

I would grade the CardioChek PA device a B- for the purposes of home users.

Somewhat related to where this may go in 5-10 years, I was able to identify an amazing illustration, showing various ranges for numerous blood metrics:

Reference ranges for blood tests

Knowing that a single drop of blood could theoretically yield all these metrics makes for some interesting ideas about how the consumer could have access to these metrics on a daily basis, at their home.

Another interesting opportunity for this market would be to introduce a blood sensor without the embedded interface that could communicate with an iPhone, similar to how the Withings BP Cuff works. I have that Withings device at home, and plan on developing a review of that device later.

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

Appling Kiviat Visualizations to Clinical Quality Measures

2012-09-02T00:33:00.002-04:00

I have been working with Clinical Quality Measures (CQMs) for several years, leading two open source healthcare projects for the Office of the National Coordinator for Health Information Technology (ONC), first popHealth and more recently Cypress. Both of these projects cover intimate details relating to CQMs. While working in this space, I have noticed that there is a need for better techniques for the visualization and presentation of Clinical Quality Measure results.

CQMs are reports that measure the quality of healthcare providers against patient-level data. CQMs are designed to measure the performance and quality care that a healthcare provider applies to a population of patients. Many factors are included in CQMs such as health outcomes, processes and systems in place at a facility, patient perceptions, and treatments provided. The idea behind introducing CQMs into the healthcare provider workflow is that continuously measuring providers against these metrics, the US healthcare system can be shaped to gradually provide higher quality and improved efficiency by monitoring these metrics.

CQMs are a required component of Meaningful Use requirements for the Medicare and Medicaid Electronic Health Record (EHR) Incentive Programs. This program is a significant part of the HITECH Act. The Meaningful Use program can supply healthcare providers with up to $44,000 in incentives if they demonstrate that they meet requirements to "Meaningfully Use" an Electronic Health Record software system in their practice.

While the notion of measuring clinical performance has been around for ages, the importance CQMs withing the Meaningul Use program has been a forcing factor to motivate EHR software vendors. All are motivated to support calculation for the Meaningful Use CQM reports in their products. Since CQMs are a feature EHR vendors must support for this federal program, there have been several visualization techniques to present CQM results to their users:

NextGen Mammography Screening CQM Visualization

This NextGen design requires a good amount of looking back/forth to understand the time interval being applied to the individual bar charts on the mammography report. This alone is my biggest grievence with the design. However, the legend on the upper left of the bar chart, actually cuts off the top of results for women who have had a mammography screening in the past 12 months. This legend background is the same tone black as the background of the bar chart illustration. This decision ultimately results in seeing a visual representation of that metric that is lower than the actual numeric value.

GE Hospital (Inpatient) CQM Dashboard

This GE dashboard makes liberal use of color to differentiate the various clinical families, and provides no visual indication on the actual CQM results. The user is force to click on each box to both understand the value, as well as the name of the specific metric. I found this technique to be one of the more painful to use.

Admittedly, after several years leading popHealth, a Clinical Quality Measure reference implementation software service, we have likewise struggled with the visualization we developed. Our popHealth CQM visualization has been warmly viewed by both clinicians and EHR vendors, but uses significant screen real estate for displaying numerous CQM results:

popHealth Practice-Level CQM Dashboard

One approach to the visualization of Clinical Quality Measures that I haven't seen wide adoption is the use of a Kiviat chart. Kiviat charts, or sometimes referred to as Radar Charts, are two dimensional, multi-metric illustrations which use a variable number of evenly distributed radii. Each spoke is associated with one metric. The length of a value overlaid on each radii is proportional to the magnitude of the metric relative to the maximum value of the variable across all data points.

Use of Kiviat diagrams works well with an apples-to-apples comparison of multiple metrics against an arbitrary number of metrics. Kiviat diagrams can also make it easier to identify patterns in data if the radii are arranged in a consistent order from diagram to diagram.

After searching for Clinical Quality Measures and Kiviat visualizations, I was able to find a good article from PIIM Research detailing numerous visualizations for clinical metrics, "Advancing Meaningful Use: Simplifying Complex Clinical Metrics Through Visual Representation". This paper included a Kiviat visualization for some CMQs, and also notes the value in providing national averages as an overlay to differentiate the delta from the measured results for one provider with a Kiviat approach:

PIIM Research Advancing Meaningful Use: Simplifying Complex Clinical Metrics Through Visual Representation

While I am unaware of target metrics or a national average for the Meaningful Use CQM results, I like the concept of presenting targets for CQMs, here presented as a black underlay. One aspect that is absent from this approach is a way to present when the providers' results exceed the target metrics. The approach above with the national average is good for presenting when there is a deficit in the results. However, it does not present a good way to visualize when CQM results exceed targets and expectations.

I do not endorse the liberal use of color in this design either. From my experiences developing command and control systems, I have found that using red or green in any design will immediately convey goodness or badness associated whatever metric is being presented. This PIIM design uses a spectrum of colors to indicate where each CQM's results are, in addition to having the Kiviat line as way to present this information.

I found the use of red and green to be very distracting when interpreting the notional results in the illustration. In particular, the name color green will appear on the CQM metrics at the same numeric value. However, targets for each measures in the example will vary on a measure-by-measure basis. I could easily imagine a light green CQM result (in the mid-80s) that might actually be very poor against a national average. Similarly, an orange/red CQM result (in the mid-60s) could easily exceed the national average and expectations.

The dark/light alternating background doesn't have any real value aside from showing the upper bounds on the entire space. While this is probably good from some users, I found it to be unnecessary.

What's my suggestion?

A few years ago, I worked with Involution Studio creative director Juhan Sonin when he was at MITRE. I have also attended and enjoyed designer Stephen Few's course on business dashboard design. See my attempt at an amalgam of Juhan's minimalist/clean visualizations using Kiviat graphics with Stephen's constant guidance to focus on the critical information below:

Juhan Sonin's Kiviat illustration, re-purposed against synthetic data for
Meaningful Use Stage 1 Clinical Quality Measures

Taking this design further, and by overlaying best practice targets with the individual results, users can quickly understand where the quality of care meets/exceeds/fails expectations:

The decision to use red as the best practice number is that when the red Kiviat is visible, it implies that the provider's performance is below the targets that she/he should be meeting. The use of blue for the measured results was primarily to made to select a color that would compliment the red. I couldn't find any good tones of green that would work without making the illustration look like it had a "Christmas" theme.

To my knowledge, the best practice metrics for any of the nationally recognized Clinical Quality Measures (Meaningful Use program, PQRS program, Pioneer ACO program... etc) are not yet established. I don't know if there is work being planned to identify what these targets need to be.

A strength and limitation to applying Kiviat illustrations in this way is that the power to rapidly assess metrics "at a glance". For instance, the ability to recognize patterns through shapes alone is could provide the ability for an analyst to rapidly review the results of numerous physicians to identify specific providers who need to address improvements on the care they provide their patients on specific diseases and demographics.

What are some potential downsides to using Kiviat diagrams with CQMs?

A potential problem is that Kiviats benefit from standardization to the placement of the particular metrics to allow for the rapid visual inspection of the CQM results. For example, changing the placement of the hemoglobin A1C metric, after an analyst had been trained on one particular illustration, would probably result in increased cognitive load and/or errors. If the location of the individual CQM metrics are standardized, it will alleviate the need for users to re-read the names of the metrics every time they were presented to users.

Additionally, there are some limitations to Kiviat illustrations endemic to the visualization technique itself. One weak spot I have noticed is the sensitivity to changes in higher-ranging metrics tends to be more exaggerated over the same magnitude of change on smaller-ranging metrics. For example, a before/after 40% increase (from 50% to 90%) on the Diabetes LDL Management CQM below yields a more striking increase to the surface area in chart. Meanwhile, a 40% reduction in the Diabetes Urine Screening CQM (from 50% to 10%) is the same change in the number of diabetic patients, but is less pronounced.

See below for a before/after example that highlights changes of the same magnitude, but a perception of a larger change on the larger valued metric:

Another challenge to using Kiviat visualizations assumes that the higher the CQM result, the better the performance and quality of care by the provider. This isn't always the case with the 44 Meaningful Use Stage 1 Ambulatory CQMs. For instance, NQF 0059: Diabetes HbA1c Poor Control considers patients meet the requirement for this CMS if the hemoglobin A1c value in diabetic patients is in an undesirable range > 9%.

This type of CQM is "legal" logic. However, the fact that the measurement grades an undesirable result complicates the approach to visualize this result with other more desirable metrics, such as NQF 0575: Diabetes HbA1c Control, which considers a hemoglobin A1c value < 8%.

One simple (albeit crude) solution to this problem would be to ensure that all future Clinical Quality Measures endorsed by the National Quality Forum (NQF) are required to associate "goodness" with meeting the numerator criteria for any CQM.

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