Business Cases and MeaningfulUse

Recently Norman (@HITDefined on Twitter) pondered about Meaningful Use Stage 2 and 3, and wondered what I thought about it with respect to reporting lab results to public health regarding reportable and notifiable conditions.  I'm quoting his post summarizing his responses to the CCHIT Survey results below:

Submission of Reportable Lab Data (and reconciliation with orders). Respondents believe that this measure is not appropriate until we have more standardized lab results coding (beyond numerical values), transmission and implementation guidance.

I agree with this, this is why standards are important….. I wonder what MotorCycle Guy thinks about this.. Going to have to ask him on twitter I believe.

First of all, my thoughts on reportable conditions are that they should be reported by the groups that generate them, not necessarily by the recievers of the information.  Why?  Economically, there are more recievers than their are generators, so that reduces overall implementation costs. Generators of the results will also be able to report them sooner than the recievers of the information might, which offers further advantages to surveillance efforts.

Where some things get complicated: 
Hospitals have their own labs, and so are originators of information (from their laboratory information systems, which are often integrated with their EHR systems).  The Stage 1 menu set includes sending reportable condition data from hospitals, but realistically, this reporting should be from the hospital lab information system, not from the EHR.  Oh well, that rule is final, and unlikely to change in Stage 2 or 3.

What if a reportable condition is detectable using a rapid point of care test (for example, if Strep Throat was a reportable disease).  At that point Healthcare providers can be the originator of the information, and would have to report electronically.

On that last one, the real question becomes an issue of cost and ROI.  A small physician practice might not even have enough reportable activity to even make it worthwhile to automate this process, whereas the State or Local health department might certainly benefit from automation.  Going back to the principal of putting the cost burden on the organization that gains by it, it would seem that automation of reporting might best be addressed by state and local health departments (there are 50+ state health departments, and a heck of a lot more providers).

Interestingly enough, the cost equation also effects hospitals as well.  One of my standards colleagues from IHE/HITSP/HL7 works in the public health space.  They report that their local hospital spends about 30 minutes a day dealing with public health reporting in a paper process.  That's for a mid-sized hospital (more than 200 beds).

One of the challenges for the hospital is that they must report to both state and local public health, and cannot use the same processes for each.  That is SO broken.  If they have to report to state public health, why do they also need to report to local public health?  Couldn't local public health get their data from the state?  Or visa-versa.  Too many silos here, and making these transactions electronic won't necessarily make those silos disappear, and meaningful use won't solve that.

Assuming that 30 minutes is for one staffer for 7 days a week, that has a modest fully burdened cost of about $9100 / year.  What's an electronic submission interface going to add to their costs to set up and maintain?  If an interface costs $10,000 to implement (a conservative estimate, it could be lower), and 20% annually thereafter to maintain, and needs to be upgraded every few years for meaningful use, this may break even or even be a small savings for them.  So, where is the business case for the MU criteria?  In an ideal world these are all good ideas, but every one has a related cost, and an expected savings and benefit.  A lot of the meaningful use criteria has obvious business cases and benefits, but others are not so obvious, and the benefits are not necessarily to the providers.

One of the additional requirements for Stage 3 proposed was that patient contact information be reported in 30% of cases.  OK, so that could run afoul of state laws, regulations and policies.  While Federal HIPAA regulation grants an exception to public health regarding PHI, it only sets a floor, not a ceiling, and state laws can vary.  State public health agencies might also find it more cost effective to maintain systems that don't require PHI for reportable conditions, only gathering that data when necessary for public health needs. Managing PHI storage requires greater security, policy and technology investments, and so can be more costly.

Now, back to Norman's discussion, which is simply about codes for reporting.  There's really no reason that I can see why laboratories cannot report LOINC codes.  Many do so already for their required reporting to public health.  I think the real challenge is not technology, but rather avoidance of further commoditization of laboratory testing.  If the LOINC codes are the same, it becomes feasible to compare lab tests on an apples to apples basis.  The labs will argue that these are apples and oranges, but would the providers?  If so, they could use a more specific LOINC code that required a particular test method, but most don't seem to care.  My provider has switched back and forth between labs for reasons that are unknown to me for some of my labs, and I'm sure it's not the method used (it's just a lipids panel).  Meaningful Use is not a lever that presently applies to labs though, only to their customers, and so only very indirectly can it change the space. Ad as far as providers are concerned, it's not them, but their customers (who pass the costs on to the payers, who bills employers, who takes it out of our salaries).

So, I don't have any clear recommendations to make here.  I'm not familiar enough with the costs and potential savings for this issue to have an obvious resolution one way or another.  The technology is certainly present and capable of supporting the requirements, but as to whether these are the right requirements, what the benefits will be on healthcare spending, and whether the costs are reasonable is not something I have the answers to.  I DO know that I want my labs to use the same codes when they are measuring the same things, and that I want those codes to be LOINC. 

Putting requirements on labs and on state/local public health are other steps that could be used to lower costs, but Meaningful Use focuses on just one part (direct care delivery) of an entire healthcare system.

It would be interesting to see a report on costs, benefits and savings for the meaningful use criteria, broken down by who pays, who benefits, how, and where the savings goes.

I've written so often on these topics that I've created a new category (HealthROI) for this blog in which I'm going to gather this and related posts.  You'll also see it as a twitter hash tag.

A Review of ONC Proposed Initiatives for HealthIT Standards and Interoperability

General Comments
ONC needs to read  The Standards Value Chain: Where Health IT Standards Come From before assigning timelines.  Their timelines are very aggressive for going from availability of implementation guides to deployment in software.  Without an external driver (like Meaningful Use), there is little to increase demand, especially when other things (such as Meaningful Use) demand work in other areas.  But also, ONC needs to take into account what the healthcare Industry has the capacity to adopt.  There are 12 initiatives listed below, and 11 of them are supposed to be operational at some level somewhere between 2011 to 2013.  Given Meaningful Use 2012 is right around the corner (from an implementer perspective), I think there needs to be a wider spread.  Sure, I'd like it sooner, but capacity is hard to increase without changes in process.  Few of these projects speak specifically to how they address that issue.


Clinical Summary
The scope of this effort is unclear given that the challenge is very poorly stated.  The definitions of the data elements for the HITSP C32 Version 2.5 appear in HITSP C154.  C154 follows best practices for data element definition that is rarely followed anywhere else (HL7 Vocabulary does some of it, but few others).  Every data element is uniquely identified, named, AND defined, and includes data element constraints on values.  Further detail on vocabulary is completely aligned with vocabularies SELECTED by ONC for Meaningful Use.  Complaints about ambiguity in vocabulary should be addressed, but please recall that it was ONC and not HITSP which created the ambiguity.

Realistically, the challenge is getting at the requirements from the available documentation, and that requires collaboration between HL7, IHE and ONC, along with tooling such as MDHT's CDA Tools work.  That collaboration has been started and should be continued.  This initiative should be combined with the Templated Clinical Documents because the two are quite overlapping in scope.  CCD is but one of many possible clinical summaries, as I've mentioned previously.  Any challenges in using CCD would be experienced with any other clinical summary developed in that effort unless both are resolved.

Templated Clinical Documents
The challenge and scope statements here clearly describe the problems and a way forward.  This is highly relevant, and work already in progress.  Most of the templates can be found in the CDA Tools work today, and appear in the HITSP C83 specification, which implementors of CCD/C32 will be readily familiar with.

Lab Interface Improvement
Been there, done that.  Hopefully this project will write the guide and not spend yet more time reevaluating vocabularies.  HL7 2.5.1 (because it meet CLIA requirements), LOINC for orders (300 codes cover 95+% of orders) and results (another set being developed by Regenstrief), SNOMED CT for body parts and pathogens, and RxNORM for drugs.  Write the guide, and get the labs to conform.

Medication Reconciliation Improvement
This is a really good idea, but the scope statement is not very clear.  IHE is working on the Reconciliation profile and I'd love to get some help on that from ONC.  We've already had some discussion on problems and our scope includes medications if we can fit it in.  Additional resources would help.

Provider Directories
I testified on provider directories to the HIT Policy committee a few months back, and there is as they note, an IHE Healthcare Provider Directory profile (pdf) on this.  This might focus on open source implementations of the IHE profile in support of The Direct Project and others like it.

Syndromic Surveillance
ISDS just sent around another version of the document for review, as I reported earlier this month.  I think they just write the guide in HL7, as recommended.

Quality Measures
They got it right about linkage between standards, vocabulary and measures.  The REAL challenge is making sure that evidence based medicine is linked to measures to start off with.  I've talked about how quality processes need to have measurement built in previously.  Previous work on quality measure specifications in HL7 was rushed due to contract deadlines, but will be taken up again in a new project that SDWG and CDS workgroups are expected to be collaborating upon again.  It's goint to take TIME to do this right. 

Population Health Query
There are two big challenges here.  The first is addressing privacy and security concerns on third parties being able to query institutional data.  The second one (partially addressing the first) would be describing aggregate queries in an appropriate form; so that results are not just deidentified, but also aggregated in the responses.  2012 is very aggressive for this.

Clinical Decision Support
My most and least favorite topic.  It's my most favorite because the opportunity to improve care is almost boundless.  It's my least favorite topic because it attracts quite a bit of academic interest, many of whom have been locked in ivory towers.  Theres so much going on in this space it's hard to keep track of.  It's completely wrong to try to exchange rules first, but that's the holy grail so everyone starts there.  The FIRST step is to identify the data needed to be exchanged to support evidence based medicine, including clinical decision support and quality measurement.  The SECOND step automates interfacing to ensure such information can be exchanged without creating new interfaces manually.  The THIRD step involves standardizing how the information is used computationally, and is what academics seem to have gotten hung up on.   But computation is programming, and you need to use the right tool for the job, and that includes programming languages.  Some problems could be pattern matching, others rule based, and other intensely computational.  Few languages support all paradigms equally, which is why I avoid the temptation to create another language for CDS.

IHE's Patient Care Coordination domain developed the Query for Existing Data (QED pdf), Care Management (CM pdf) and Request for Clinical Guidance (RCG pdf) profiles to support this kind of exchange.  It is still ahead of its time mostly because it addresses the SECOND step without strongly addressing the FIRST.  QED may finally have gained enough implementors to go final this year.

Blue Button
Blue button is a much discussed initiative developed originally by Markle and implemented by VA and DoD.  The chief problem with blue button is its fixation on human readable text.  I'd prefer to see more work to take standards based XML and make it human readable, rather than generate text versions of the standards.  The self-displaying CDA project in HL7 is one such effort.

Green Button
This is the weakest of all of the proposals.  The value to providers is pretty good for that once every 5-10 year period that they consider replacing there EMR system with something from a different vendor, but it does nearly nothing to address day-to-day value in healthcare.  Yes, it would open up the EMR market and prevent lock-in, and that has value, but I think the cost savings possible here are really quite a bit smaller than for any of the other initiatives.

Value Set Development
Value set development on lab orders is done and similar work on results is in process by LOINC.  Other necessary value sets might include anatomy and pathogens.  HITSP C80 described the value set for anatomy as: Shall contain a value descending from the SNOMED CT® Anatomical Structure (91723000) hierarchy or Acquired body structure (body structure) (280115004) or Anatomical site notations for tumor staging (body structure) (258331007) or Body structure, altered from its original anatomical structure (morphologic abnormality) (118956008) or Physical anatomical entity (body structure) (91722005).  Pathogens could also come from SNOMED CT.

The real challenge is not in defining the value sets, but rather making them deployable and publically available.  IHE has developed the Sharing Values Sets profile (SVS pdf) that could support exchanging standardized value sets in XML.

Prioritizing ONC Initiatives for HealthIT and MeaningfulUse

Recently ONC published a request for feedback on the Standards and Interoperability Framework Prioritization process and proposed initiatives. An overview of the S&I framework can be found here (pdf).

 

They ask two key questions on the prioritization criteria (xls):

• Are the current criteria appropriate and sufficient to evaluate Initiatives?
• Are there additional criteria within the four categories that should be included?

And then they ask you to assess the initiatives (ppt) based on your own weights using the spreadsheet.

 

The S&I Prioritization framework is a good start. It provides some process on making decisions about how initiatives are to be prioritized, but doesn’t get into several details that are of interest to the healthcare industry. Notably absent from this spreadsheet is who gets to participate in these evaluations and how. A prioritization process that does not include affected stakeholders is of limited value.  There needs to be more detail added to the prioritization framework to determine how stakeholder input is provided.

 

The prioritization spreadsheet represents a decision making workflow that should be addressed in stages. Relevance should not be weighed against or alongside feasibility. If the project isn’t relevant, then feasibility doesn’t matter and visa-versa.

 

The scoring and weighting is completely unspecified in the priorities. It would have been better to provide some guidance in this framework so that it could be spit on or applauded. Having nothing at all is not the best way to get feedback. On having both scores and weights, I’d simply drop one or the other altogether. The scores ought to be used to assess a SINGLE initiative, not compare two or more against each other.  Scoring should be relatively straightforward and something that the committee can reach concensus on.  A five point scale ranging from Low, Low-Medium, Medium, Medium-High, High, or similar is easiest to use to reach consensus.  The scores are used to facilitate final decision making, not to "make" the decision for you.  This accounts for individual weighting of the importance of the activities.

 

These initiatives cannot really be compared to each other, but are part of a portfolio of initiatives. An initiative that completely nails ONE goal, at low cost, high chance of success, and with few resources SHOULD be strongly considered. But one that hits 10 on goals, costs 5 times as much, and has a 50% chance of success, might likely be scored as being equivalent to the former using a linear weighting system, but should be INTENSELY reviewed before adoption.

 

The first stage of the evaluation should assess the relevance of the initiative. Initiatives that are not relevant need no further evaluation. Relevance of an initiative should also account for subsequent initiatives which it enables. In IHE, relevance of profile proposals is addressed by the planning committee. For the S&I framework, these might be assessed by the HIT Policy Committee.

 

The next stage of evaluation should address feasibility. Initiatives which cannot be done because they are not yet feasible should be postponed until such time as they become feasible, and a reassessment of relevance should be done at that time also. For initiatives which are not feasible, a question that should be asked is what could make this initiative feasible. That question may identify enabling initiatives which should be done first. In IHE, the feasibility is assessed by the technical committee. In the same vein, feasibility for S&I would be assessed by the HIT Standards Committee.

 

Relevance and feasibility feed into a third decision making step. That step compares costs of proceeding with the project (which can be assessed during the feasibility phase) to the expected benefits (which can be assessed during the relevance phase). There really isn’t any tab in the ONC S&I Prioritization Framework that addresses cost/benefit or return on investment. The costs should also look at opportunity cost. The prioritization framework must assume finite resources to complete initiatives. Executing one initiative may consume resources needed for another (opportunity cost). It should also consider what other initiatives might be enabled (benefits) by a project. There needs to be some guidance in the framework to determine the extent of resources available for execution. Cost/Benefit and ROI decisions should be jointly assessed based on relevance and feasibility.  Aligned with cost/benefit or ROI evaluation, is a determination of likelyhood of effectiveness. Some of that is described in the usability/accountability tab. If the question of effectiveness cannot be answered, then research or pilots should be done first prior to starting a large project.

 

This is essentially the same thing that any good organization goes through in prioritizing projects to be completed. Will this project meet the needs of our organizational stakeholders and their mission? Can it be done? Are the benefits worth the cost (what is the ROI)? Will it be useful and effective?

 

If you have looked at the spreadsheet supplied by ONC, you’ll note that I’ve addressed three of their four areas, and did not address Evidence-Based Medicine and Research Support. These are simply questions focused on relevance of the initiative, as focused by existing EBM and Research initiatives. I see no need to call these out separately.

 

So, here are the changes I recommend to the Prioritization Framework:

1. Group everything on Relevance in one place (including applicability to EBM and Research Goals)
2. Add a section on costs and potential savings / benefits. It may be hard, but any good organization estimates costs and benefits before initiating projects.
3. Develop a way to determine available resources, and ensure that each project / initiative specifies resource needed for success, INCLUDING volunteer resources.
4. Ensure that the prioritization process includes adequate industry input from providers, payers, vendors and consumers. Each project should have input from affected industry stakeholders, not just assessments from HIT FACAs.
5. Drop weights, and use simpler scoring criteria, recongizing that weights are subjective and that initiatives cannot be compared to each other

There are two things that the prioritization process also needs to account for.  One is that there must be an opportunity to say NO to an initiative.  HITSP never had that opportunitity and was expected to "scale up" 100% year over year.  If NO cannot be said to a proposed S&I initiative, then the same problem will appear there.  Also, S&I needs to account for, and allow for initiatives to fail.  Failures teach as much or more as successes.  If we aren't failing, we aren't trying hard enough.

  

Tomorrow (or Wednesday if I run out of time), I'll post my assessment of the initial proposals...

Ranking Interoperability

I always appreciate it when important ideas can be communicated in easy to understand ways.  One of my colleagues recently did that in a way that impressed me over dinner at the HL7 Working Group Meeting last week.  Scott Bolte describes, using the lens of "Healthcare Economics," a method to evaluate interoperability opportunities rather concisely.  

My own post on Scope and Focus was written shortly after our conversation, and I had asked Scott for help putting together a more detailed post on his topic for this blog.  I think after you read what he has to say, you will see how the two pieces are tied together. 

Scott sent me his bullet points on the conversation via e-mail, and it was so simply written, yet easily understood that I post it below without change.  Here are his words:

---

How to compare interoperability opportunities...

1. high disease penetration in a population.
2. high societal cost burden.
3. highly motivated patients.
4. there is a meaningful intervention.
5. opportunity to improve situation with improved interoperability.

#1 makes sure healthcare providers will see the condition often enough to invest their time and money adopting any improved capabilities.

#2 improves the odds that payors will reimburse.

#3 is critical to healthcare provider engagement.

#4 means there is a chance to move the dial.

#5 is actually a fill-in-the-blank. The first four can be used to assess any opportunity, but in this case it's to determine if improved interoperability is worth pursuing.

People who are worried that going after only the big hitting diseases does a disservice to rare conditions should be reassured that once the improved interoperability is working, it will benefit all similar scenarios.

Scope and Focus

One of the places I've been paying attention to in HL7 and in our national program is how to make the best use of resources.  I've had some very interesting discussions on this topic over the last three weeks on both fronts.  One of my concerns about our national program is that we seem to be getting distracted by every good idea.  The same thing is true in HL7.  For example, here are a list of projects in HL7 that are in some ways trying to facilitate use of HL7 standards:

1. Green CDA
2. Micro-ITS
3. New ITS
4. RIM ITS
5. Mapping Tools
6. Templating Tools
7. Template Registry Pilot 
8. Virtual Medical Record
9. Netrual Mapping Notation
10. CDA Release 3
11. Common Document Types
12. hData ITS
13. Template Design Pilot
14. ... (I think you get the point)

The good thing about these is that they are aligned to some degree to a strategic initiative.  The bad thing is that there really is no overall architecture that explains how all of these things work together, and how they are tied into that strategic initiative.

On top of that are all of the other projects that are coming in that are not related to a strategic initiative.

Each project has a cost in time and effort, not only in members that are active in development of the project, but other members who observe, participate and vote to approve the project and its outputs (standards and implementation guides).

There are limited resources in any organization, and I know in most businesses, that for every project suggested and approved, there are probably 2 to 10 that didn't make the cut because they don't offer sufficient return on investment.  Since these standards are our products in HL7, we should be making some business decisions about the projects to produce them that affects what we deliver to our customers (and as I've noted before, our customers and our members are two different audiences).  That means that occasionally we need to say no, and that we need to better align and coordinate those projects that are part of strategic programs.

The same thing is true in our national program.  We are about to see use cases coming out of the woodwork.  We need to develop a framework of governance that ensures these uses cases are

1. Aligned with National Strategic Initiatives
2. Will have a reasonable impact, based on an assessment of the increases in effectiveness, outcomes or access, and the efforts involved.

I'll be trying to figure out how we accomplish this over the next couple of years, both in HL7 and in the US

Questioning the Question

Some days things come out of my mouth that make me stop and want to say: Why didn’t I think of that? The internal conversation continues something like this: But you just did. Okay, why didn’t I think of that sooner? Sometimes it takes the right question at the right time to cause my brain to synthesize a good (and sometimes even really good) response.

The question at this particular point in time was: How can I query for a document containing certain information I need. I stopped the questioner to provide me with more context, as I usually do. Essentially, I’m trying to get at the real problem. The problem in this case was a process where a patient is sent for referral, and certain clinical data is sent with the referral. The clinical data being sent is specified by an implementation guide that indicates required and optional data. In some number of cases though, the optional data is more important than others. It depends on the clinical context, and it’s hard to judge when it will be valuable.

The questioner didn’t have all the details on how often this would occur, how likely it would be to delay care. The proposed process simply mirrored an existing paper referral process, but put more interoperability requirements around it.

There are two ways to solve this person’s problem. Solution 1 would have been to simply answer his question. I could have done that using at least three different standards or implementation guides or IHE profiles, some of which are more mature than others.

The problem can also be simply resolved using solution 2. Solution 2 makes all of the data necessary to make any referral decision required in the original content sent with the referral. This has a related implementation cost, which is unknown, but can be estimated. The other solution, send data that is easy to get to and in exceptional cases perform at least one, and possibly more round trip communications to get additional data when needed also has costs, also unknown but also estimable.

The right answer in this case is to do a bit more digging before coming up with a solution.

Let’s look at some examples using imaginary data. I’ll use $5,000 / year as the generic annual maintenance cost of a single interface, and multiply that value by a factor of 10 for initial implementation of each interface. These are imaginary values. They could be higher or lower, and the purpose is not to scare anyone, just to show an example of the analysis.

Solution 1 has 6 interfaces, two outbound on the referrer side, one inbound on the referrer side, and two inbound in the referred to side, and one outbound on that side. For the sake of argument, let’s assume that the two outbound and inbound interfaces are identical, it’s just the addition of a query / response pair. That gives us a total of four interfaces that have to be implemented and maintained, with some interrelated moving parts. That adds up to an implementation cost of $200K for the four interfaces, plus $20K per year to maintain them.

Solution 2 is a bit more complicated to implement for the outbound and inbound interfaces, call it a 50% increase in implementation cost, but the same costs to maintain them. Solution 2 has an outbound interface on the referring side, and an inbound interface on the referred to side. The total implementation cost is $150K for these two interfaces, and annual maintenance is $10K / year.

Taking the analysis that far would indicate an immediate win for solution 2, but let’s assume that it wasn’t an immediate win and take the analysis further. Let’s say it was three times harder to implement the more complex interface. You’d be at $300K to implement, and $10K / year to maintain, which would take 10 years to provide sufficient ROI for this solution to become equal in cost to solution 1 (300K + 10K * 10 = 200K + 10 * 20K = 400K).

So far, so good, we understand the analysis. But against implementation costs we also have to weigh other possible costs and risks to see what could be tolerated. Solution 1 incorporates a potential workflow delay. Anytime a delay is introduced into a workflow, we have to ask ourselves what the impact would be on patient care, and whether it introduces a risk to the patient. If 1 referral out of 20 needs more data, and the delays introduced in getting that data result in an impact in patient care again, 1 time out of 20, is that an acceptable risk? Is one chance in 400 an acceptable likelihood for this risk? I cannot answer this question without knowing the possible impact on the patient (it could even be me). If life threatening, then I certainly wouldn’t accept those chances, but if this is simply a minor inconvenience, I might.

If the patient is being referred for consultation on a potential cancer finding, a delay in the referral process could introduce a life threatening risk, but for a routine and non-life-threatening condition, it might not.

Now, let me take this one step forward into implementation guide development. We have two different use cases, and in those, two different potential solutions, each with associated costs, and different risk profiles depending upon the context. The referral process is a common use case that can be as simple as a referral to an ENT for an ear infection, or as complex as a consult for a patient with a possible cancer diagnosis. The choices we make for the content to be exchanged is broad because the use case is broad, and without more specifics, we cannot require more data because it would introduce an implementation cost that might not be acceptable for a wide variety of common use cases. That has to be weighed against other use cases that require more stringent controls on data exchange, because these address rarer, but also, disproportionately more complex and costly care.

How do you weigh the value of these two use cases against each other? What choices do you make about the data that is required and optional to cover both these cases (assuming you even know about these two cases in the first place). What is the value of the solution for the common but not life-threatening solution? That value of the solution for rarer but life-threatening cases?

I don’t have a good process to explain to others on how to decide this sort of thing. For one, I’m not clinical, so I have to rely on the clinical judgment of others to make many of these assessments. Secondly, there isn’t really a way to objectively measure these risks. To do so would be to put a value on the cost of human life, which may be technically feasible, but is arguably infeasible in so many other ways.

There are some tools that we can use. Cost / benefit calculations, even using fictional data can be very revealing. If you are right even on the order of magnitude here, the results to the real world are often comparable^{[citation needed]}. Risk assessments are also extremely valuable, and should be done even before cost / benefit calculations. Even with these tools though, expanding a use case to provide broader coverage can make things too complicated to completely analyze using these tools. Then, you just have to go with your gut.

In some ways, standards development is still an art. Someday it will become a science, and when we get there, I’ll know it, because there will be nothing else left for me to do but enjoy life. I hope that day comes when or after I decide to retire.

^{[citation needed]} I wish I could find the research that backs this up. When I do get into a Masters program it would be an interesting topic for further study.

Taking cost out of the system

A lot of the work I've been doing is focused on taking costs out of healthcare.  One of the principles I try to apply rigorously is to ensure that the largest cost burdens are borne by the systems at the center.  Image that you have 100 systems connecting to one central hub.  Imagine further that there is some complex processing needs to take place during commmunications between those systems and the hub.  Where do you put the expensive node?  Why at the center of course.  Similarly, you avoid trying to change workflows at the edges because those also incure costs.

Yet when we talk about quality reporting, most of the quality reporting initiatives put the burden at the edge, and everyone reports nicely computed measures to the center.  Instead of incurring costs at a few centralized hubs, providers at the edge are incuring pretty substantial costs (see Cost to Primary Care Practices of Responding to Payer Requests for Quality and Performance Data in the Annals of Family Medicine). 

What if, instead of reporting the measures, we reported the values that went into the measurement using existing workflows.  What if the centralized hubs were responsible for computing the measures based on the "raw data" recieved.  Yes, the centralized hubs would need to do a lot more work, BUT, even if that work were two or three orders of magnitude larger than it is today, the number of edge systems is 5 to 6 orders of magnitude larger than the number of central hubs.  If you have 100,000 systems communicating with you, it's certainly in your best interest to make "your job" simpler and easier and reduce your costs.  But if you are a centralized system, and "your job" also includes paying for 60% of healthcare costs, then you have a different economy to consider.  The costs incurred at the edge don't impact you today, but they will indirectly impact your bottom line tommorow.

The HL7 QRDA specification goes a long way towards relating the data used to compute quality measures back to the data used in Electronic Medical Record systems.  However, it still requires more effort at the edge than some other approaches, as it still requires computatation at the edge.  It also needs to be built upon a foundation that is designed for quality reporting rather than clinical documentation.

The HL7 eQMF specification strikes at the problem from a different angle and takes a slightly different approach.  This specification should be able to:

a) Define the raw data needed to compute measures,
b) Specify how the measures themselves are computed.

If it performs both of these functions, then electronic medical record systems should be able to report the "data they have" to systems that can compute quality measures.  This should result in a far lower implementation burden than trying to get thousands of different organizations to implement and report on these computations, and it will also help to stabililize the measures.  The measures will all be computed the same way based on the raw data.  Variations in how the measure is interpreted are eliminated or dramatically reduced.  This should result in even better (or at least more consistent) measures.

IHE has developed a profile for Care Management that could readily support the reporting of the raw data (ok, so it is HL7 Version 3, SOAP and Web Services based, but that IS another discussion).  The missing specification in that profile is the one that tells it what data needs to be reported.  That could easily be eQMF.  I live in hope.