   |
 |
| View Message Online >> |
- Free Webinar -
Release of the 2011 Report on HIE: Sustainable HIE in a Changing Landscape
|
Date: Thursday, November 10, 2011 from 3:00 - 4:00 PM ET
eHealth Initiative will be presenting a webinar featuring results from their annual 2011 Health Information Exchange (HIE) Survey that focuses on the issue of sustainability. This 60 minute session will provide data on a critical issue in the implementation and maintenance of HIEs across the United States. This webinar, led by Jason Goldwater, Vice President of Programs and Research, will focus on the following:
 |
eHealth Initiative | 818 Connecticut Avenue | Suite 500 | Washington, DC 20006 | United States
|
Monday, October 31, 2011
Sustainable HIE in a Changing Landscape (Free Webinar)
This looks like it might be worth listening to...
Friday, October 28, 2011
Half of ACO Quality Measures are in MeaningfulUse
I was doing a review of the ACO Quality Measures yesterday. One thing I noted was that at least half of them are also in Meaningful Use. The cool thing about that is that this team has already reported that most MU measures can be computed from the HITSP C32 with the addition of procedures section, and that nearly all can be addressed by adding smoking status and vitals (see pages 4-6 of their paper).
What about the other half? Well, six of them come from what will now be a CMS supported survey, three of them come from claims data, and another one comes from Meaningful Use attestation reports. So, of the remainder, what isn't in Meaningful Use Stage 1, and can it be computed from the HITSP C32?
These are the remaining measures:
What about the other half? Well, six of them come from what will now be a CMS supported survey, three of them come from claims data, and another one comes from Meaningful Use attestation reports. So, of the remainder, what isn't in Meaningful Use Stage 1, and can it be computed from the HITSP C32?
These are the remaining measures:
- Medication Reconciliation at Discharge (NQF #97)
- Fall Risk Screening (NQF #101)
- Depression Screening (NQF #418)
- Proportion of Adults 18+ who had their Blood Pressure Measured within the preceding 2 years (CMS)
- Diabetes Measures (NQF #729
- Ischemic Vascular Disease (IVD): Complete Lipid Profile and LDL Control (NQF #75)
- Treatment for CAD w/ Diabetes/LVSD (NQF #66)
Looking at each of these:
Fall Risk (#2) and Depression (#3) screening assessment scores can be recorded in the HITSP C32 Results section. So, if you find an assessment result, you can tell that these have been done.
The diabetes measures (#5) are from the MN Community Measurement instrument. These account for five separate measures in the ACO rule and are very simple to compute from CCD medications, results, vital signs or social history (for tobacco use) sections:
- HgA1C < 8
- LDL < 100
- BP < 140/90
- Tobacco Non-Use
- Aspirin Use
The IVD (#6) and CAD (#7) measures can also be readily computed, as they are very similar to other computable results in Meaningful Use stage 1.
That just leaves #1, Medication Reconciliation on discharge. Because the CCD is not a discharge summary, you'd really want to look at a different document to compute that measure. But if you did open up a discharge summary, and found one of the required entries of the IHE RECON profile, you could be assured that medication reconciliation was performed at discharge.
So, half of ACO measures are meaningful use measures, and you should be able to compute nearly all of the the other half from the standards already required for Meaningful Use stage 1. And it could even get better under stage 2 when we have other documents supported for Transitions of Care.
Thursday, October 27, 2011
CDA Consolidation: It's a Library, not just a Book
We've had several discussions on the CDA Consolidation guide project on one of my negatives. As originally stated, I was proposing that we remove the required LOINC code for CCD 1.1 (yes, there will be a new version of the CCD when the CDA Consolidation guide is done). The rationale for this suggestion was that we want there to be a way to say: "It's a CCD", without fixing the document type.
As the discussion went on, it evolved into there existing a template identifier that indicates "This document conforms to all applicable sections and entries (and documents), found in the CDA Consolidation guide".
This feature was already present in the HITSP C83 specification, and is reproduced below. As such, it is certainly within the scope of the HL7 project to ensure that this feature is reconciled along with the IHE and HL7 guides.
What is the point of it?
The main point is that the CDA Consolidation guide, like the CCD, IHE PCC Technical Framework and HITSP C83 specifications that it harmonizes, is a library of documents, sections and entries. In IHE we've found that the IHE PCC Technical Framework is more widely used as a library of sections and entries than the individual document templates specified within it. The IHE section and entry templates are presently in use in national projects in the US, Europe, Japan and China. The same is true for CCD template (there are over 20 implementation guides using CCD templates). We can certainly expect, based on that experience that the same will also be true for the CDA Consolidation guide. The HITSP guide not only anticipated this behavior based on prior experience, but also promoted it through the above conformance rules.
What are the benefits of asserting this template identifier?
Suppose that you have developed an application that understands the CDA Consolidation guide, and gathers information from appropriate sections on problems, medications, and allergies. Now, you want to use this application, but someone has determined that they need a new document type not covered by the guide. As an example, let's look at an assessment of health and functional status for long term care use. This clearly isn't covered by the current set of documents in the CDA Consolidation guide.
But, if someone were to create a new implementation guide, and use the CDA Consolidation guide sections and entries, my application could take advantage of that fact. There is a major concern here, which is a potential impact on patient safety. Suppose my application uses the information in this document, specifically on problems, medications, and allergies, to provide some clinical decision support for the patient assessed in the document. Suppose also that the creators of that assessment instrument (a CDA implementation guide), decided that they didn't like the way that CDA Consolidation dealt with allergies, and so they used an incompatible model. What could happen? Well, if you didn't know that they used a different model for allergies, when you tried to extract the allergy information, your application would either not find it, or not find all the details recorded in the same way as they had been recorded according to the consolidation guide. As an end result, you wouldn't have the allergy information, and could produce incorrect, perhaps even dangerous results.
Now, how can you tell that they've used templates you understand. In this particular example, you'd make a list of the templates you need, and then go check to make sure that the document incorporated them. This particular example is deliberately simplified, so maybe you only need the handful of sections and entries related to problems, meds and allergies (there's at least a dozen of these). Even having checked that, you really don't have any assurance that they haven't added another section that does things differently in a way that you don't understand.
What the CDA Consolidation template identifier would do is tell you that the document has done things the CDA Consolidation guide way for everything that overlaps in anyway with what already exists. That means that it doesn't record the same information present and described somewhere in the guide in a way that it NOT compatible with the guide.
This gives the receiving system a statement of assurance that says, if CDA Consolidation guide did it this way, this document does it this way as well. That means that the receiving system has less to worry about with respect to information being recorded differently from what it already understands.
This is exactly the rationale that HITSP used when adding these conformance statements to the C83 specification in support of the Clinical Note Details use case. And in fact, someone did create a guide just like the one I just described that conformed to the HITSP template for C83. It was the CARE-SET implementation guide used in the C-HIEP demonstration project. And guess what, that project also used MDHT.
Granted, just because someone asserts the template identifier, it doesn't mean that you can simply assume that what they've done is correct. You also have to be able to test conformance to it.
How can you test this?
Some of the opposition seems to come from "we don't know how to automate the test." There are assertions in the CDA Consolidation guide that have implications, and there are some unstated assumptions that may need to be made more explicit. If the section template id is X, then the LOINC code for the section must be Y. In most cases for these documents, there should be only one section of that type, so:
So, you can detect non-conforming sections and entries where these kinds of assertions (and assumptions) are present. You can also detect non-conforming entries with similar constraints on code (or other attributes) or detect missing entries from sections. You can also identify specific entry classes that do not conform to template identifiers in the guide for inspection to see whether or not they overlap.
One of the challenges here is figuring out how to create the appropriate tests based on the data that is used to generate the guide. This may be a technical challenge, but just because there is a technical challenge shouldn't be an impediment to implementing the idea. It's certainly feasible. The MDHT project managed it (see slide 8) for C-HIEP.
How does this benefit implementation guide and standards developers?
A guide that requires the assertion of the Consolidation template identifier in instances is itself asserting that it doesn't doesn't conflict with the CDA Consolidation guide. That means that it, and any additional templates it creates would be more easily considered for inclusion into the next edition of the consolidation guide. A guide that doesn't do this requires a deeper look for gaps and overlaps. It also means that when such a guide is reviewed and approved, reviewers can point out inconsistencies not just as potential problems, but rather as implementation guide errors.
How this simplifies creation of other guides?
All of the rules, all the logic, all the consistency implied in the guide is asserted in one little statement. If, as a CDA implementation guide creator, I am ready to trust in the CDA Consolidation guide, then I can turn my attention to other things that guide doesn't support. This is extremely powerful. You can adopt hundreds of pages of specification, and avoid countless hours of struggle, and there's even a way to say you did just that. If we want to make it easy to create implementation guides (e.g., using tools like MDHT) to meet other use cases, this is the kind of thing that we need to consider.
I've been through this process not once, not twice, but many times. In IHE adopting from HL7 CCD, in HL7 adopting from IHE PCC, in HITSP adopting both, and back again in HL7 with the consolidation guide. If we want "one ring to bind them", it needs to have a name, and I need to be be able to use it meaningfully. This would be extremely important for IHE adoption, because we want to ensure consistency. IHE already has document content that isn't included in the CDA Consolidation guide. How would we be able to assert consistency with it?
What does optional or recommended really mean?
A guide that asserts the Consolidation template identifier is stating that it is doing things consistently with what the guide indicates. If the guide says that severity is recorded in this way, and the instance record severity differently, and the severity assessment is optional, has the guide conformed? While the instance might conform to the allowed model, it really has failed to follow the intent of the guide. The guide says to record severity this way, and the instance didn't. This is an incompatibility that would later need to be resolved if the new guide were "brought in" to the CDA Consolidation guide.
It's a brand, not just a guide!
This is my last rationale for inclusion of this, and probably the weakest from a technical perspective, but strongest from an implementation perspective. As HL7 learned from developing the CCD, everybody wanted to be able to call everything a CCD, but not everything was. This gives HL7 something that allows everybody to use CDA Consolidation, even when it doesn't have the exact document they need, and still claim conformance to the guide.
As the discussion went on, it evolved into there existing a template identifier that indicates "This document conforms to all applicable sections and entries (and documents), found in the CDA Consolidation guide".
This feature was already present in the HITSP C83 specification, and is reproduced below. As such, it is certainly within the scope of the HL7 project to ensure that this feature is reconciled along with the IHE and HL7 guides.
Please note that the following constraints have been added to support the creation of structured documents using the templates defined in this section. The last two constraints are to ensure that a CDA document conforms to the HITSP defined sections and entities where these entries are available. If HITSP has not created an appropriate entry or section, the CDA document MAY include those.
C83-[CDA-10] CDA document instances that adhere to the specifications for the sections and entries defined within this specification MAY declare their conformance to these constraints by including <templateId> element with a value of 2.16.840.1.113883.3.88.11.83.1 in the root attribute and no extension.
C83-[CDA-11] Conforming CDA document instances SHALL conform to the HITSP defined sections* where available
C83-[CDA-12] Conforming CDA document instances SHALL conform to the HITSP defined entries** for clinical statements where available
* If the intent of the section is to capture information that could be captured in an existing HITSP section, the section shall conform to the HITSP defined section (although it may be further constrained).There are a couple of key questions around this proposal:
**If the intent of the entry (clinical statement) is to capture information that could be captured in an existing HITSP entry, the entry shall conform to the HITSP defined entry (although it may be further constrained).
What is the point of it?
The main point is that the CDA Consolidation guide, like the CCD, IHE PCC Technical Framework and HITSP C83 specifications that it harmonizes, is a library of documents, sections and entries. In IHE we've found that the IHE PCC Technical Framework is more widely used as a library of sections and entries than the individual document templates specified within it. The IHE section and entry templates are presently in use in national projects in the US, Europe, Japan and China. The same is true for CCD template (there are over 20 implementation guides using CCD templates). We can certainly expect, based on that experience that the same will also be true for the CDA Consolidation guide. The HITSP guide not only anticipated this behavior based on prior experience, but also promoted it through the above conformance rules.
What are the benefits of asserting this template identifier?
Suppose that you have developed an application that understands the CDA Consolidation guide, and gathers information from appropriate sections on problems, medications, and allergies. Now, you want to use this application, but someone has determined that they need a new document type not covered by the guide. As an example, let's look at an assessment of health and functional status for long term care use. This clearly isn't covered by the current set of documents in the CDA Consolidation guide.
But, if someone were to create a new implementation guide, and use the CDA Consolidation guide sections and entries, my application could take advantage of that fact. There is a major concern here, which is a potential impact on patient safety. Suppose my application uses the information in this document, specifically on problems, medications, and allergies, to provide some clinical decision support for the patient assessed in the document. Suppose also that the creators of that assessment instrument (a CDA implementation guide), decided that they didn't like the way that CDA Consolidation dealt with allergies, and so they used an incompatible model. What could happen? Well, if you didn't know that they used a different model for allergies, when you tried to extract the allergy information, your application would either not find it, or not find all the details recorded in the same way as they had been recorded according to the consolidation guide. As an end result, you wouldn't have the allergy information, and could produce incorrect, perhaps even dangerous results.
Now, how can you tell that they've used templates you understand. In this particular example, you'd make a list of the templates you need, and then go check to make sure that the document incorporated them. This particular example is deliberately simplified, so maybe you only need the handful of sections and entries related to problems, meds and allergies (there's at least a dozen of these). Even having checked that, you really don't have any assurance that they haven't added another section that does things differently in a way that you don't understand.
What the CDA Consolidation template identifier would do is tell you that the document has done things the CDA Consolidation guide way for everything that overlaps in anyway with what already exists. That means that it doesn't record the same information present and described somewhere in the guide in a way that it NOT compatible with the guide.
This gives the receiving system a statement of assurance that says, if CDA Consolidation guide did it this way, this document does it this way as well. That means that the receiving system has less to worry about with respect to information being recorded differently from what it already understands.
This is exactly the rationale that HITSP used when adding these conformance statements to the C83 specification in support of the Clinical Note Details use case. And in fact, someone did create a guide just like the one I just described that conformed to the HITSP template for C83. It was the CARE-SET implementation guide used in the C-HIEP demonstration project. And guess what, that project also used MDHT.
Granted, just because someone asserts the template identifier, it doesn't mean that you can simply assume that what they've done is correct. You also have to be able to test conformance to it.
How can you test this?
Some of the opposition seems to come from "we don't know how to automate the test." There are assertions in the CDA Consolidation guide that have implications, and there are some unstated assumptions that may need to be made more explicit. If the section template id is X, then the LOINC code for the section must be Y. In most cases for these documents, there should be only one section of that type, so:
- X -> Y (template id X implies LOINC code Y)
- |Y| = 1 (there shall only be one occurence of LOINC code Y)
- |Y| !-> X -> (|Y| > 1) (if Y does not imply X, then there could be more than one section with LOINC code of Y)
- Thus, Y -> X (so, in a conforming instance, if the LOINC code is Y, the template ID must be X)
So, you can detect non-conforming sections and entries where these kinds of assertions (and assumptions) are present. You can also detect non-conforming entries with similar constraints on code (or other attributes) or detect missing entries from sections. You can also identify specific entry classes that do not conform to template identifiers in the guide for inspection to see whether or not they overlap.
One of the challenges here is figuring out how to create the appropriate tests based on the data that is used to generate the guide. This may be a technical challenge, but just because there is a technical challenge shouldn't be an impediment to implementing the idea. It's certainly feasible. The MDHT project managed it (see slide 8) for C-HIEP.
How does this benefit implementation guide and standards developers?
A guide that requires the assertion of the Consolidation template identifier in instances is itself asserting that it doesn't doesn't conflict with the CDA Consolidation guide. That means that it, and any additional templates it creates would be more easily considered for inclusion into the next edition of the consolidation guide. A guide that doesn't do this requires a deeper look for gaps and overlaps. It also means that when such a guide is reviewed and approved, reviewers can point out inconsistencies not just as potential problems, but rather as implementation guide errors.
How this simplifies creation of other guides?
With one assertion, I can adopt all the rules in the CDA Consolidation guide. Essentially, I've declared:
import org.hl7.sdwg.CDAConsolidation.*; (for Java developers)
using org.hl7.sdwg.CDAConsolidation; (for C# developers)
All of the rules, all the logic, all the consistency implied in the guide is asserted in one little statement. If, as a CDA implementation guide creator, I am ready to trust in the CDA Consolidation guide, then I can turn my attention to other things that guide doesn't support. This is extremely powerful. You can adopt hundreds of pages of specification, and avoid countless hours of struggle, and there's even a way to say you did just that. If we want to make it easy to create implementation guides (e.g., using tools like MDHT) to meet other use cases, this is the kind of thing that we need to consider.
I've been through this process not once, not twice, but many times. In IHE adopting from HL7 CCD, in HL7 adopting from IHE PCC, in HITSP adopting both, and back again in HL7 with the consolidation guide. If we want "one ring to bind them", it needs to have a name, and I need to be be able to use it meaningfully. This would be extremely important for IHE adoption, because we want to ensure consistency. IHE already has document content that isn't included in the CDA Consolidation guide. How would we be able to assert consistency with it?
What does optional or recommended really mean?
A guide that asserts the Consolidation template identifier is stating that it is doing things consistently with what the guide indicates. If the guide says that severity is recorded in this way, and the instance record severity differently, and the severity assessment is optional, has the guide conformed? While the instance might conform to the allowed model, it really has failed to follow the intent of the guide. The guide says to record severity this way, and the instance didn't. This is an incompatibility that would later need to be resolved if the new guide were "brought in" to the CDA Consolidation guide.
It's a brand, not just a guide!
This is my last rationale for inclusion of this, and probably the weakest from a technical perspective, but strongest from an implementation perspective. As HL7 learned from developing the CCD, everybody wanted to be able to call everything a CCD, but not everything was. This gives HL7 something that allows everybody to use CDA Consolidation, even when it doesn't have the exact document they need, and still claim conformance to the guide.
Be Afraid of EHR
Be Afraid.
EHRs are going to be more widely used. Therefore:
Never mind that:
EHRs are going to be more widely used. Therefore:
- There will be increased hazards with respect to provider liability in their use.
- Plaintiffs might use your EHR data against you.
- Use of electronic records might land you in court.
Never mind that:
- Physicians who use EHRs pay fewer malpractice claims.
- Or that use of CPOE and Clinical Decision Support can reduce medication errors.
- Or that EHRs can cut long term operating costs.
- Or that EHRs could improve the quality of care.
Because, after all, change in the way medicine is practiced is always risky. Therefore it should be avoided.
So, remember and be afraid.
Wednesday, October 26, 2011
Killing Eterna-threads: REST vs. SOAP
In software design, especially the design of information systems, there is still no one true way. Anyone with experience in the "Art" of software design understands this. There are lots of different ways to do things, and some are better and some are worse, and which one is better often depends upon the environment, use case, and requirements of the situation.
Often when I'm asked a question about "Should I do X or Y?" or "How do I do X?", my first response is "What are you trying to do?" I'm trying to understand the environment, use case, and requirements that will let me suggest one solution or another based on my expertise.
Just last week I was in a room full of W3C Standards and IT Experts. These included authors/editors of W3C standards, committee chairs, book authors, et cetera. The debate over REST and SOAP which we've frankly stopped discussing for a while in Healthcare IT is still going strong over there. One thing that was truly obvious to the experts in THAT room is that the relevant points in the REST vs. SOAP debate depends upon the environment. In "the web", REST dominates with loose binding, dynamic, resource-oriented approaches, and ad-hoc mash-ups. In "the enterprise", SOAP dominates with strong contracts, definable composition approaches, strong security models, and expected and pre-agreed upon behaviors.
I've seen eterna-threads before ... you know, those debates that never die, and never get solved either. I build rules for them in my e-mail client so that they get appropriately routed. The challenge here is not one of science. These debates cannot be addressed in an OSI 7-layer model. Instead, you have to jump to OSI-layer 8 or 9 (religion/philosophy and politics) to understand them. The two camps have even been identified as "Cats" and "Dogs". I'm stuck in the middle.
To give an example, the author of the Web Application Design Language (WADL) was present at the meeting I attended. He reports how he was resoundingly "spanked" for not understanding the RESTful "philosophy" regarding interface contracts. Arguably, that author understands RESTful approaches as well as any practitioner of the art. In fact, what he did was bring in a requirement "outside" the typical environment where RESTful approaches work, and attempted to integrate that requirement into a RESTful framework. Since the REST crowd didn't see that as a requirement of their "typical" environment, they rejected it as being antithetical to the RESTful approach.
Fielding's paper describes REST as an architectural style and demonstrates its appropriateness for the web. What others are wanting is a demonstration of this particular style's appropriateness for other environments, such as the enterprise. We would like to see how features of the current "SOAP" style (e.g., contracts, definable composition, pre-agreed upon or well-defined behaviors, and strong security models) could be addressed using a RESTful approach.
One of the outcomes of the meeting was a suggestion to document best practices in RESTful approaches, and to describe how some of these other requirements: Strong contracts, well-defined behaviors, and strong security models can be applied to REST. As several "RESTful" experts acknowledge, these aren't antithetical to the approach, they simply haven't been well documented and understood by that community.
It is my sincere hope that a document how REST can work in the enterprise environment is produced, and that it might help the rest of us understand. If it gets done well, perhaps we can put this eterna-thread to REST.
Tuesday, October 25, 2011
SIFramework Face to Face update on QueryHealth
I spent some time in the Query Health Clinical and Implementation workgroups at last week's S&I Framework face to face meetings. There were a number of interesting discussions, and David Tao reports on some of them in his blog post today. I'm a bit behind on my own report out, so here it is, with a few [side rambles] included.
One of the discussion points in the Clinical Workgroup was on the user stories. We were looking at the various user stories and expanding upon what they do. We quickly got bogged down into discussions on quality metrics. But the key point in Query Health is not just quality reporting. There are a lot of different things that it can report on:
[One of the complaints about eMeasures is that it "is new", but the fact of the matter is that a lot of Query Health is "new". Sure, there is some existing work, but we are trying to put a lot of that together in ways that can be supported across the spectrum of Health IT and that hasn't been done before. At the moment, it really is the only standard that declaratively specifies the structure of some sort of counter]
One of the discussion points in the Clinical Workgroup was on the user stories. We were looking at the various user stories and expanding upon what they do. We quickly got bogged down into discussions on quality metrics. But the key point in Query Health is not just quality reporting. There are a lot of different things that it can report on:
- Quality Measures (an obvious use case)
- Population Stratification
What does your population look like when stratified against a particular disease risk?
e.g., Who should get a limited supply of a particular immunization? - What medications and adverse events are correlated (e.g., Heart Attack and Vioxx)?
- What is the trend with respect to some particular condition over time?
So, we broke that log-jam and got focused on some other stories that might look a bit different. One common feature of many of these user stories is the focus on "counting", so we are now talking more about counters, rather than numerators and demoninators (which are just specialized counters).
Another interesting discussion in the Implementation workgroup was on how we should proceed. What kinds of technologies that we've seen thus far seem promising? This was, as on person put it (not me, although it was attributed to me on the Query Health review call today because I said it again later in the meeting), a "Beauty Contest". Three different systems stood out, but by far, the hQuery proposal backed by MITRE seemed to get the most support. I had a hard time choosing because I've been behind on my summer concert listening (ONC recorded a dozen 90-minute presentations from invited guests who might have a solution to the problem). But I did have some idea about what hQuery was, and thought it might be a good place to start.
One of the things that I don't like about hQuery right now is that it seems to be tied too much to JavaScript, and to a Map/Reduce based algorithm. While JavaScript is extremely available, and Map/Reduce is very scale-able, there are definite challenges to adapt it to a wide variety of implementations. I'd much prefer a more declarative approach, using something like the Transitions of Care Clinical Information Model (CIM) as the basis for the declarations.
The TOC CIM is based on the HITSP C154/C83/C80 work (data elements, information models, and vocabulary) that goes into all HITSP Document specifications, including the C32. One concern of the Implementation workgroup is the weak modeling of Encounters in the TOC CIM. According to one participant, we needed to modify the TOC CIM to create our own model. I like to think about that differently. We (the Query Health project) need to modify the S&I Framework CIM to meet our requirements. Note how I changed the ownership of the work product from TOC to S&I Framework. If S&I Framework is to survive, it needs to stop organizing itself solely in a project centric fashion.
[One suggestion I made for the next S&I Face to Face meeting was to develop tracks: Clinical, Implementation/Technical, and Operational/Business. In that way, folks who have deep knowledge in one of those areas can contribute to more than one project. Right now, we don't have that structure, and it means that I, and others like me, spend a lot of time communicating across and trying to follow different projects and workgroups within projects. It's very difficult to follow more than one activity when everything is going on all at the same time. If S&I Framework isn't careful, they'll have as many workgroups as HL7.]
I was in MITRE offices later in the week for a W3C Workshop on Data and Services Integration. After the workshop, I was given a brief overview of hQuery by Marc Hadley, an organizer of that workshop and one of the designers of hQuery. He showed me their "Query Builder", which describes what results a clinician might be looking for. The JavaScript on the back end is actually produced from the content specified in the Query Builder. I think there are some opportunities here to use some of the HL7 HQMF modeling (eMeasures) work do help declaratively define the results, along with the CIM model (based on C32 and other HL7 CDA documents), and the general framework of hQuery for distribution and reporting.
[One of the complaints about eMeasures is that it "is new", but the fact of the matter is that a lot of Query Health is "new". Sure, there is some existing work, but we are trying to put a lot of that together in ways that can be supported across the spectrum of Health IT and that hasn't been done before. At the moment, it really is the only standard that declaratively specifies the structure of some sort of counter]
Among the benefits of using a declarative structure based on a reference model are:
- Queries can be defined based on what the user wants to see.
- EHR and Health IT systems can map the query to whatever framework they want to use. It could be SQL, Map/Reduce, Extract/Transform/Load or any other approach. It isn't tied to any specific architectural model.
The hQuery work already shows that they can transform against a "Green" C32 model into a Map/Reduce architecture using JavaScript. Those details are all necessary to produce a working implementation. But they aren't all necessary to produce the set of standards that defines how Query Health works.
An interesting side-note here is in a recent paper presented at AMIA by John D’Amore, Dean Sittig and Adam Wright titled: The Promise of the CCD: Challenges and Opportunity for Quality Improvement and Population Health. In it the authors note that 12 of the 44 (a little more than one fourth) Meaningful Use Stage 1 Ambulatory quality measures could be extracted from the example CCDs containing problems, medications and allergies, and that 35 of the 44 (about 80%) could be extracted by adding procedures. With the addition of other data, the authors note that they could extract all the ambulatory measures.
This is a pretty significant result for Query Health because it means, at least for one of the pilots, that there is evidence that they can succeed, as most of their data is coming from documents using the C32 specified content.
An interesting side-note here is in a recent paper presented at AMIA by John D’Amore, Dean Sittig and Adam Wright titled: The Promise of the CCD: Challenges and Opportunity for Quality Improvement and Population Health. In it the authors note that 12 of the 44 (a little more than one fourth) Meaningful Use Stage 1 Ambulatory quality measures could be extracted from the example CCDs containing problems, medications and allergies, and that 35 of the 44 (about 80%) could be extracted by adding procedures. With the addition of other data, the authors note that they could extract all the ambulatory measures.
This is a pretty significant result for Query Health because it means, at least for one of the pilots, that there is evidence that they can succeed, as most of their data is coming from documents using the C32 specified content.
Query Health is an interesting project. I'm hoping that it will produce something useful without being to restricting on the technology that is used to implement it. So far, it seems to be headed in the right direction.
-- Keith
-- Keith
Monday, October 24, 2011
Got ACO? You will still need EHR and HealthIT
OK, so I've just finished plowing through nearly 700 pages of the ACO Final Rule. I also bookmarked the Preview copy, so you can download it from Google Docs for your own reading enjoyment ;-)
As a patient, my main focus in reviewing the rule is what it does for me. There are few changes from my original review that really impact patients here, except in:
For those of you who are interested in how ACOs will be measured, Table 1 from the final rule shows the quality measures (You can also find this on page 324 of the final rule text in the Federal Register Preview).
Table 1 Measures for Use in Establishing Quality Performance Standards that ACOs Must Meet for Shared Savings
*We note that this measure has been under development and that finalization of this measure is contingent upon the availability of measures specifications before the establishment of the Shared Savings Program on January 1, 2012.
In case you want a quick summary of what's changed financially, Table 5 from the final rule summarizes the changes between the Proposed rule and the Final Rule. You can also find this on page 396 of the Final Rule text (in the Federal Register Preview).
Table 5: Share Savings Program Overview
As a patient, my main focus in reviewing the rule is what it does for me. There are few changes from my original review that really impact patients here, except in:
- How ACO providers are measured on quality (the final rule uses 33 measures phased in with respect to performance, whereas the proposed rule had 65),
- The requirement that a certain percentage of ACO providers were meaningful users of HealthIT.
- That Federally Qualified Health Centers and Rural Health Centers can now form (by themselves) and better participate in ACOs (which is great if you happen to live in a rural or underserved area).
In general, the requirements for patient engagement, and patient participation in ACO governance are still present.
From the Health IT side, I was interested in how the changes impacted the Health IT industry. They removed a specific requirement on the number of ACO Professionals who are Meaningful Users, but that doesn't really worry me. Measure 11 has double weight, and is "% of providers who are meaningful users", so that will still have an ACO program impact.
My 140 character summary of the ACO rule from a Health IT perspective? "Got ACO? You'll still need EHR and HealthIT, even if the regs don't require it."
The reason for that is the amount of coordination that will be needed by members of the ACO. The point of shared savings is that the providers actually get a benefit for not duplicating work. So, if the lab was already done, and provider A has it, then provider B (and everyone else) can potentially benefit from the savings when Provider B uses the existing result. Recently my wife had knee surgery. The surgeon wanted a recent EKG. He would have been incented (under the savings model), to reuse the one my wife already had. Perhaps not as much as he might have earned from doing it over, but the world is not perfect.
There are a couple of places where Health IT and EHRs will really matter to ACOs:
- Assessing the health needs of the patient population.
- Identifying High-Risk Individuals and support of individualized care planning
- Supporting the use of evidence based medicine (e.g., through clinical decision support).
- Reporting on Quality Measures
- Managing care through an episode, including transitions between providers
- Dealing with monthly claims data and quarterly aggregates
Page 178 of the Final Rule points out that coordination of care between ACO participants and non-participants is one way to accomplish ACO goals. Amusingly enough, some commenters were looking for CMS to fund some of the IT Investments needed. CMS points these commenters to the Meaningful Use program for Health IT and EHR incentives.
For those of you who are interested in how ACOs will be measured, Table 1 from the final rule shows the quality measures (You can also find this on page 324 of the final rule text in the Federal Register Preview).
| # | Domain | Measure Title | NQF Measure #/ Measure Steward | Method of Data Submission | Pay for performance R = Reporting P=Performance | ||
| Year 1 | Year 2 | Year 3 | |||||
AIM: Better Care for Individuals
|
|||||||
| 1 | Patient/Caregiver Experience | CAHPS: Getting Timely Care, Appointments, and Information | NQF #5, AHRQ | Survey | R | P | P |
| 2 | Patient/Caregiver Experience | CAHPS: How Well Your Doctors Communicate | NQF #5 AHRQ | Survey | R | P | P |
| 3 | Patient/Caregiver Experience | CAHPS: Patients' Rating of Doctor | NQF #5 AHRQ | Survey | R | P | P |
| 4 | Patient/Caregiver Experience | CAHPS: Access to Specialists | NQF #5 AHRQ | Survey | R | P | P |
| 5 | Patient/Caregiver Experience | CAHPS: Health Promotion and Education | NQF #5 AHRQ | Survey | R | P | P |
| 6 | Patient/Caregiver Experience | CAHPS: Shared Decision Making | NQF #5 AHRQ | Survey | R | P | P |
| 7 | Patient/Caregiver Experience | CAHPS: Health Status/Functional Status | NQF #6 AHRQ | Survey | R | R | R |
| 8 | Care Coordination/ Patient Safety | Risk-Standardized, All Condition Readmission* | NQF #TBD CMS | Claims | R | R | P |
| 9 | Care Coordination/ Patient Safety | Ambulatory Sensitive Conditions Admissions: Chronic Obstructive Pulmonary Disease (AHRQ Prevention Quality Indicator (PQI) #5) | NQF #275 AHRQ | Claims | R | P | P |
| 10 | Care Coordination/ Patient Safety | Ambulatory Sensitive Conditions Admissions: Congestive Heart Failure (AHRQ Prevention Quality Indicator (PQI) #8 ) | NQF #277 AHRQ | Claims | R | P | P |
| 11 | Care Coordination/ Patient Safety | Percent of PCPs who Successfully Qualify for an EHR Incentive Program Payment | CMS | EHR Incentive Program Reporting | R | P | P |
| 12 | Care Coordination/ Patient Safety | Medication Reconciliation: Reconciliation After Discharge from an Inpatient Facility | NQF #97 AMA-PCPI/NCQA | GPRO Web Interface | R | P | P |
| 13 | Care Coordination/ Patient Safety | Falls: Screening for Fall Risk | NQF #101 NCQA | GPRO Web Interface | R | P | P |
AIM: Better Health for Populations
|
|||||||
| 14 | Preventive Health | Influenza Immunization | NQF #41 AMA-PCPI | GPRO Web Interface | R | P | P |
| 15 | Preventive Health | Pneumococcal Vaccination | NQF #43 NCQA | GPRO Web Interface | R | P | P |
| 16 | Preventive Health | Adult Weight Screening and Follow-up | NQF #421 CMS | GPRO Web Interface | R | P | P |
| 17 | Preventive Health | Tobacco Use Assessment and Tobacco Cessation Intervention | NQF #28 AMA-PCPI | GPRO Web Interface | R | P | P |
| 18 | Preventive Health | Depression Screening | NQF #418 CMS | GPRO Web Interface | R | P | P |
| 19 | Preventive Health | Colorectal Cancer Screening | NQF #34 NCQA | GPRO Web Interface | R | R | P |
| 20 | Preventive Health | Mammography Screening | NQF #31 NCQA | GPRO Web Interface | R | R | P |
| 21 | Preventive Health | Proportion of Adults 18+ who had their Blood Pressure Measured within the preceding 2 years | CMS | GPRO Web Interface | R | R | P |
| 22 | At Risk Population - Diabetes | Diabetes Composite (All or Nothing Scoring): Hemoglobin A1c Control (<8 percent) | NQF #0729 MN Community Measurement | GPRO Web Interface | R | P | P |
| 23 | At Risk Population - Diabetes | Diabetes Composite (All or Nothing Scoring): Low Density Lipoprotein (<100) | NQF #0729 MN Community Measurement | GPRO Web Interface | R | P | P |
| 24 | At Risk Population - Diabetes | Diabetes Composite (All or Nothing Scoring): Blood Pressure <140/90 | NQF #0729 MN Community Measurement | GPRO Web Interface | R | P | P |
| 25 | At Risk Population - Diabetes | Diabetes Composite (All or Nothing Scoring): Tobacco Non Use | NQF #0729 MN Community Measurement | GPRO Web Interface | R | P | P |
| 26 | At Risk Population - Diabetes | Diabetes Composite (All or Nothing Scoring): Aspirin Use | NQF #0729 MN Community Measurement | GPRO Web Interface | R | P | P |
| 27 | At Risk Population - Diabetes | Diabetes Mellitus: Hemoglobin A1c Poor Control (>9 percent) | NQF #59 NCQA | GPRO Web Interface | R | P | P |
| 28 | At Risk Population - Hypertension | Hypertension (HTN): Blood Pressure Control | NQF #18 NCQA | GPRO Web Interface | R | P | P |
| 29 | At Risk Population – Ischemic Vascular Disease | Ischemic Vascular Disease (IVD): Complete Lipid Profile and LDL Control <100 mg/dl | NQF #75 NCQA | GPRO Web Interface | R | P | P |
| 30 | At Risk Population – Ischemic Vascular Disease | Ischemic Vascular Disease (IVD): Use of Aspirin or Another Antithrombotic | NQF #68 NCQA | GPRO Web Interface | R | P | P |
| 31 | At Risk Population - Heart Failure | Heart Failure: Beta-Blocker Therapy for Left Ventricular Systolic Dysfunction (LVSD) | NQF #83 AMA-PCPI | GPRO Web Interface | R | R | P |
| 32 | At Risk Population – Coronary Artery Disease | Coronary Artery Disease (CAD) Composite: All or Nothing Scoring: Drug Therapy for Lowering LDL-Cholesterol | NQF #74 CMS (composite) / AMA-PCPI (individual component) | GPRO Web Interface | R | R | P |
| 33 | At Risk Population – Coronary Artery Disease | Coronary Artery Disease (CAD) Composite: All or Nothing Scoring: Angiotensin-Converting Enzyme (ACE) Inhibitor or Angiotensin Receptor Blocker (ARB) Therapy for Patients with CAD and Diabetes and/or Left Ventricular Systolic Dysfunction (LVSD) | NQF # 66 CMS (composite) / AMA-PCPI (individual component) | GPRO Web Interface | R | R | P |
*We note that this measure has been under development and that finalization of this measure is contingent upon the availability of measures specifications before the establishment of the Shared Savings Program on January 1, 2012.
One-Sided Model
|
Two-Sided Model
|
|||
Issue
|
Proposed
|
Final
|
Proposed
|
Final
|
Transition to Two-Sided
Model
|
Transition in third
year of first agreement period
|
First agreement period
under one-sided model. Subsequent agreement periods under two- sided model
|
Not Applicable
|
Not Applicable
|
Benchmark
|
Option 1 reset at the
start of each agreement period.
|
Finalizing proposal
|
Option 1 reset at the
start of each agreement period.
|
Finalizing proposal.
|
Adjustments for health
status and demographic changes
|
Benchmark expenditures
adjusted based on CMS-HCC model.
|
Historical benchmark
expenditures adjusted based on CMS-HCC model. Performance year: newly
assigned beneficiaries adjusted using CMS-HCC model; continuously assigned
beneficiaries (using demographic factors alone unless CMS-HCC risk scores
result in a lower risk score). Updated benchmark adjusted relative to the
risk profile of the performance year.
|
Benchmark expenditures
adjusted based on CMS- HCC model.
|
Historical benchmark
expenditures adjusted based on CMS-HCC model. Performance year : newly
assigned beneficiaries adjusted using CMS-HCC model; continuously
assigned beneficiaries (using demographic factors alone unless CMS-HCC
risk scores result in a lower risk score). Updated benchmark adjusted
relative to the risk profile of the performance year.
|
Adjustments for IME and
DSH
|
Include IME and DSH
payments
|
IME and DSH excluded
from benchmark and performance expenditures
|
Include IME and DSH
payments
|
IME and DSH excluded
from benchmark and performance expenditures
|
Payments outside Part A
and B claims excluded from benchmark and performance year expenditures;
|
Exclude GME, PQRS, eRx,
and EHR incentive payments for eligible professionals, and EHR incentive
payments for hospitals
|
Finalize proposal
|
Exclude GME, PQRS,
eRx, and EHR incentive payments for eligible professionals, and EHR
incentive payments for hospitals
|
Finalize proposal
|
Other adjustments
|
Include other adjustment
based in Part A and B claims such as geographic payment adjustments and
HVBP payments
|
Finalize proposal
|
Include other
adjustment based in Part A and B claims such as geographic payment
adjustments and HVBP payments
|
Finalize proposal
|
Maximum Sharing Rate
|
Up to 52.5 percent
based on the maximum quality score plus incentives for FQHC/RHC
participation
|
Up to 50 percent based
on the maximum quality score
|
Up to 65 percent based
on the maximum quality score plus incentives for FQHC/RHC participation
|
Up to 60 percent based
on the maximum quality score
|
Quality Sharing Rate
|
Up to 50 percent based
on quality performance
|
Finalizing proposal
|
Up to 60 percent based
on quality performance
|
Finalizing proposal
|
Participation
Incentives
|
Up to 2.5 percentage
points for inclusion of FQHCs and RHCs
|
No additional
incentives
|
Up to 5 percentage
points for inclusion of FQHCs and RHCs
|
No additional
incentives
|
Minimum Savings Rate
|
2.0 percent to 3.9
percent depending on number of assigned beneficiaries
|
Finalizing proposal
based on number of assigned beneficiaries
|
Flat 2 percent
|
Finalizing proposal:
Flat 2 percent
|
Minimum Loss Rate
|
2.0 percent
|
Shared losses removed
from Track 1
|
2.0 percent
|
Finalizing proposal
|
Performance Payment
Limit
|
7.5 percent.
|
10 percent
|
10 percent
|
15 percent
|
Performance payment
withhold
|
25 percent
|
No withhold
|
25 percent
|
No withhold
|
Shared Savings
|
Sharing above 2 percent
threshold once MSR is exceeded
|
First dollar sharing
once MSR is met or exceeded.
|
First dollar sharing
once MSR is exceeded.
|
First dollar sharing
once MSR is met or exceeded.
|
Shared Loss Rate
|
One minus final sharing
rate
|
Shared losses removed
from Track 1
|
One minus final sharing
rate
|
One minus final
sharing rate applied to first dollar losses once minimum loss rate is met
or exceeded; shared loss rate not to exceed 60 percent
|
Loss Sharing Limit
|
5 percent in first risk
bearing year (year 3).
|
Shared losses removed
from Track 1.
|
Limit on the amount of
losses to be shared phased in over 3 years starting at 5 percent in year 1;
7.5 percent in year 2; and 10 percent in year 3. Losses in excess of the
annual limit would not be shared.
|
Finalizing proposal
|
Subscribe to:
Posts (Atom)