How Transparency Enables Competition in a Market

So, I'm planning to have solar PV installed at my new house.  The state of Massachusetts and the federal government provide a lot of incentives to enable this.  I can get 30% of my installation cost back in federal tax credits, and something like $1000 from state credits, plus I can generate value through SRECs.  The state publishes a list of installers, as well as thes cost of installation in $/Watt. I've been using that list to pick solar companies to talk to.  The most popular installer also happens to be one of the more expensive, at $5.50/W, while others are in the $3.50 to $4.00 range.

In ONC's report on "Data Blocking", they note that pricing for interfaces is unknown.  Wouldn't it be interesting if incented providers under MU also had to report the price they paid for a system in order to get the incentive?

Oh, damn, the incentives are done. Maybe next time.

Should HL7 support Backwards Compatible only, or Backwards compatibility as an option in the CCDA 2.1 DSTU Update?

One of the outstanding questions that the C-CDA project has to address is whether the 2.1 DSTU will require backwards compatibility only, or whether there will be a mode supporting backwards compatibility, and a mode where C-CDA 2.0 constraints are simply adopted.  We haven't made a decision yet.

Some would argue that supporting backwards compatibility only will simplify the guide for people. I have argued that will require HL7 to create a new project further down the line, and will not enable C-CDA 2.1 to be used in projects which are presently dependent upon C-CDA 2.0, some of which, like QRDA, also have a regulatory component naming a version of the standard.

To move forward, I will be proposing the following wording be adopted in constraints that are added to support backwards compatibility:

To support backwards compatibility, XXX SHALL/SHOULD/MAY YYY

This highlights the constraints added to support backwards compatibility.  Then we add language to the top of the specification depending upon which choice we make:

1. If we choose backwards compatibility only, we state:
   This specification adds constraints supporting backwards compatibility.  These constraints are identified by beginning with the phrase "To support backwards compatibility", and are otherwise equivalent to any other constraint.
2. If we choose to support both, we state:
   This specification adds constraints supporting backwards compatibility.  These constraints are identified by beginning with the phrase "To support backwards compatibility."  These are conditional constraints. When a document instance declares that it is supporting backwards compatibility by [mechanism to be established], these constraints must also be followed.  

This will allow the project team to create the constraints now, and make the choice later about whether these constraints are conditional or not.

HL7 is looking for feedback on this.  If you are a member of the Structured Documents mailing list, you can provide your feedback there, or on next weeks Thursday call, or on tomorrows C-CDA 2.1 DSTU Update project call.  As always, any feedback you provide in comments here, I will also forward to the workgroup, supporting them as best as I am able even though I have my own preferences.

Personally, I could still be convinced for option 1 by an argument that resonates with my own concerns, but am still strongly leaning towards option 2.

The role of a patient with respect to their chart

For my ethics class I'm writing a term paper that develops an HL7 model showing the various entities, roles, participations and their relationships associated with health information exchange.  The point of this model is to illustrate the various roles with regard to patient data, in order to facilitate ethical evaluation of "Data Blocking".

In the process, I find that there is no appropriate HL7 Role class that can be used to relate a person to the health chart associated with their care.  The health chart role is scoped by the organization that maintains it, when in fact, I had expected it to be scoped by the patient.  The RIM also allows me to relate the organization to a patient chart via the maintainer role, so I think there's some duplication here. The best that I can do is show that the patient role has indirect authority (a role relationship) over the health chart role. But I need a direct role relationship between the patient and their chart is because roles confer rights and responsibilities. I think for this paper I'll use the patient as the scoper and connect the healthcare organization via the maintenance relationship.

This gap is interesting because it shows the disconnect in thinking about patients and their rights and responsibilities with respect to their chart.

Correcting this gap seems fairly tricky. save that there is little to no use of HLTHCHRT in the HL7 2014 Normative Edition.  It might be worth proposing that this role be deprecated, and that a new role: Patient Chart be added, where the player is the Health Chart entity, and the scoper is the Patient.

I'll have to think about that.  RIM Harmonization is a pretty challenging process, and I've already got a lot of irons on the fire (or is that FHIR?).

   Keith

The case against a negationInd extension for supply and encounter in CDA and QRDA

It's been proposed recently that the prohibition in CDA Release 2.0 against extensions altering the semantics of the information doesn't apply to RIM based extensions.  What the standard has to say in section 1.4 on Extensibility is [emphasis mine]:

Locally-defined markup may be used when local semantics have no corresponding representation in the CDA specification. CDA seeks to standardize the highest level of shared meaning while providing a clean and standard mechanism for tagging meaning that is not shared. In order to support local extensibility requirements, it is permitted to include additional XML elements and attributes that are not included in the CDA schema. These extensions should not change the meaning of any of the standard data items, and receivers must be able to safely ignore these elements. Document recipients must be able to faithfully render the CDA document while ignoring extensions.

The rationale for including this extension in QRDA is to enable one measure (of 93) to be able to report that something was not supplied to the patient.

We did a risk analysis of this today on a special Structured Documents call.  Here's the scenario:

Data is captured for quality reporting and quality improvement activities.
Within that context, rules are created to ensure that patients are followed up on if they aren't getting appropriate treatment as evidenced by supply records.

1. A patient with DVT risk is ordered prophylaxis.
2. However, that prophylaxis is not supplied for some reason (e.g., patient couldn't afford to pay).
3. This is recorded using the extension.
4. A system that uses the proposed extension will correctly detect that the supply did not occur, and can initiate followup.  However, a system that does not use the proposed extension and is developed with the understanding that unrecognized extensions can safely be ignored will not recognize that the supply did not occur.  In fact, it will instead recognize the opposite, that supply did occur.
5. As a result of this, no followup on the necessary intervention is performed.  
6. Due to the resulting delay to detect that the prophylaxis was not given, a life threatening health event occurs.

We need to assess three things:

1. The severity of harm, which we evaluated as critical/life threatening [different organizations may use different terms].
2. Probability of occurrence of the hazard: Care management systems today are looking for the absence of the supply signal.  Presenting a supply signal using QRDA with the extension will always cause this trigger to fail.  Due to the way it interferes with followup activities, is unlikely to be noticed by a provider, so the probability of occurrence is high that it will occur.
3. Likelyhood of harm: This would have to be ratedMechanical prophylaxis can reduce the risk of DVT from 27% to 13% alone, or when used with medications, from 15% to 2% [see http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1925160/].

If you work out the rest, you realize this is not really a workable solution by itself.  Something else has to be done.  Documenting the extension and putting some clear warnings around it is something we know doesn't work well.  Trying to create patient safety in a design through labeling is the least effective method according to the FDA.

If I were the product manager for the 93 quality measures, I'd pull the one in question and release it later when CDA Release 2.1 (or as seems more likely, CDA on FHIR) has the capacity to address the need.

Sproing

Boone's farm is shaping up this spring.  Quotes are on the way for Solar and the side deck, a dozen or so chicks are in their coop, blueberry netting arrived on the truck today, the first vegetables are planted, rhubarb has already been harvested at least twice, horse inquiries are making some progress, kitty cat #2 has arrived (April), kitty #1 (Ferb) and the rabbit (Nutmeg) have seen their new vet, and a new puppy is next on the list of animals to show up, along with finding someone to do the basement remodeling work.  I've negotiated a brushwacking of the back 40 (actually closer to 0.40) for a case of mead, and have to start restringing (wiring) the fencing this weekend after putting up the blueberry netting.  The smoker has already seen two roasts, and about a dozen chicken legs and wings.

On other fronts, BPMN is heating back up, the HL7 Relevent and Pertinent project was approved last week and is moving forward, C-CDA 2.1 DSTU Update is also moving forward, an IHE materials for Clinical Mapping (CMAP), Guideline Accountable Ordering (GAO), Remote Patient Monitoring (RPM) and RECON on FHIR are out for public comment, as is the DAF Implementation Guide for document access.

As classes finish up for spring, I'm enrolled in two classes next term.  I'll be helping to teach Interoperability and Standards, and will be looking forward to taking Evidence Based Medicine from my Informatics professor.

It's looking to be a productive summer.  Hopefully I can keep up.

Interoperability Then and Now

Interoperability is all the rage today, just ask twitter, the federal government, or even your local doctor.  Ten years ago, I often had to explain to people why they needed interoperability, and how to ask for it.  Now everybody is focused on it, but as some have said, I may not want to define it, but I know what it is when I see it.

The needle has swung completely the other way since then. As such needles do, this one is due for an [over-]correction.  Many providers have suggested that we don't need Meaningful Use to tell them what to do. Many patients still say that they cannot get their damned data.  After seven years of waiting, I can finally get my data, but my provider's portal barely provides any sensible presentation.

I like John's idea that we are now at the trough of disillusionment on Interoperability, and I think that it is quite true.  Now that we are paying attention, it seems like we aren't getting yet what we want. The technology might be there, but the workflows aren't, or the two aren't as tightly coupled as they could or perhaps should be.  It will be interesting to look back on this point in time about three years from now to see what we did right, and what we did wrong.

   Keith

Precision Research vs. Precision Care

One of the topics that shows up repeatedly in discussions of Comparative Effectiveness Research is the mismatch between data quality requirements in research, and that presently used in EHRs for patient care, for example, as noted in this article.

What then, are the impacts of research on care, if data gathered for care is not as precise as that used for research?

Because of these differences:

1. Patients who qualify for an intervention according to EHR data may include patients that wouldn't qualify according to the guideline produced based on the research.
2. Patients who should have qualified but didn't according to EHR data might be missed because the EHR does not capture data according to the guideline.
3. Interventions provided according to the EHR may not be the same interventions specified according to the guideline.
4. Interventions captured by the EHR that should have been appropriate according to the guideline might not be captured in a way that they are recognized as being appropriate.
5. We very likely aren't capturing the outcomes in either case, and if we are, we likely have similar challenges with regard to that data capture.

So we have noise that would introduce variability in who gets treated, and in capturing accurately who was treated and what their outcomes were.

My question is, that if research indicates the number needed to treat is say 50, what is it really given the differences between theory and practice?  Is the promise of all of this precision in medicine real? If not, what needs to happen to make it so?