Monthly Archives: August 2015

What is the state of CDA R3?

Question

We have seen references to new extension methodologies being proposed in CDA R3; however I can’t seem to find what the current state of CDA R3 is.  Most searches return old results.  The most recent document related to CDA R3 using FHIR instead of RIM.  What is the current state of CDA R3 and where can I find more information.  HL7 pages seem to be pretty old.

Answer

The Structured Documents work group at HL7 (the community that maintains the CDA standard), is currently focused on publishing a backwards compatible update to CDA R2 called CDA R2.1. CDA R3 work has been deferred to the future, both in order to allow the community to focus on R 2.1, and to allow FHIR time to mature.

There is general informal agreement that CDA R3 will be FHIR based, but I wouldn’t regard that as formal or final; FHIR has to demonstrate value in some areas that it hasn’t yet done before a final decision could be made. I expect that we’ll have more discussions about this at the HL7 working meeting in Atlanta in October.

Question: #FHIR and patient generated data

Question:

With the increase in device usage and general consumer-centric health sites (e.g. myfitnesspal, Healthvault, Sharecare) coupled with the adoption of FHIR, it seems like it is becoming more and more common for a consumer to be able to provide the ability to share their data with a health system. The question I have lies in the intersection of self-reported data and the clinical record.

How are health systems and vendors handling the exchange (really, ingest) of self-reported data?

An easy example is something along the lines of I report my height as 5’10” and my weight as 175 in MyFitnessPal and I now want to share all my diet and bio  data with my provider.  What happens to the height and weight?  Does it get stored as a note?  As some other data point?  Obviously, with FHIR, the standard for transferring become easier, however, I’m curious what it looks like on the receiving end. A more complicated example might the usage of codifying an intake form.  How would i take a data value like “do you smoke” and incorporate that into the EHR?  Does it get stored in the actual clinical record or again, as a note?  If not in the clinical system, how do I report (a la MU) on this data point.

Answer

Well, FHIR enables this kind of exchange, but as you say, what’s actually happening in this regard? Well, as you say, it’s more a policy / procedure question, so I have no idea (though the draft MU Stage 3 rule would give credit for this as data from so-called “non-clinical” sources). But what I can do is ask the experts – leads on both the vendor and provider side. So that’s what I did, and here’s some of their comments.

From a major vendor integration lead:

For us, at least, the simplest answer is the always-satisfying “it’s complicated.”

Data generally falls into one of the following buckets:

  1. Data that requires no validation: data that is subjective. PHQ-2/9.
  2. Data that requires no validation (2): data that comes directly from devices/Healthkit/Google Fit.
  3. Data that requires minimal validation: data that is mostly subjective but that a clinician might want to validate that the patient understood the scope of the question – ADLs, pain score, family history, HPI, etc.
  4. Data that requires validation: typically, allergies/problems/meds/immunizations; that is, data that contributes to decision support and/or the physician-authored medical record.
  5. Data that is purely informational and that is not stored discretely.

Depending on what we are capturing, there are different confirmation paths.

Something like height and weight would likely file into (e). Height and weight are (a) already captured as a part of typical OP flow and (b) crucially important to patient safety (weight-based dosing), so it’s unlikely that a physician would favor a patient-reported height/weight over a clinic-recorded value.

That said, a patient with CHF who reports a weight gain > 2lb overnight will likely trigger an alert, and the trend remains important. But the patient-reported value is unlikely to replace a clinic-recorded value.

John Halamka contributed this BIDMC Patient Data Recommendation, along with a presentation explaining it. Here’s a very brief extract:

Purpose: To define and provide a process to incorporate Patient Generated Health Data into clinical practice

Clinicians may use PGHD to guide treatment decisions, similarly to how they would use data collected and recorded in traditional clinical settings. Judgment should be exercised when electronic data from consumer health technologies are discordant with other data

Thanks John – this is exactly the kind of information that is good to share widely.