Adding support for CCDA

[coderdoc]

Hi, it would be great if you would add support for CCDA since C32 is pretty much obsolete and CCDA is the latest. Might want to consider FHIR too since that seems to be coming up.

[jr1968]

Just returned from HIMSS...FHIR is being heavily promoted by all major vendors.

[coderdoc]

Hi Jordan; thanks for getting back; that's a good point; you should add support for FHIR as well (how long, of course, will this go on- i.e., what's the NEXT standard around the corner!?); but, in any case, right now it's an MU requirement that every vendor can export an entire practices worth of patients as a CCDA. So, it would make a lot of sense for pophealth to be able to import those. How many years before everyone is doing FHIR?

QRDA I has never made any sense to me- "here- let me extract JUST the relevant data for every patient and measure, and give it to you, so that you can import it and then restate what I already know", as opposed to "here's all the data- now have the computer analyze it instead of me"... what are your thoughts on this?

In other words, it seems to me that it should be possible to export ALL (not select/hand picked) information on a given patient or set of patients, in a standard way, and have pophealth determine which measures the patient is in and meets. Ultimately this would lead to a service where we shoot the patient data, and the service responds with "here's how this patient is doing across all applicable measures" (with the measures maintained centrally).

With regard to CCDA and FHIR, I haven't looked at it yet, but, I would guess it's possible to write an XSLT to transform a CCDA in to FHIR. It's not possible to do that with a QRDA I.

Nice to meet you, by the way. What's your background? I've been programming PM/EHR for 18+ years. I have a lot of interest in the OSEHRA program since ultimately I believe in a centralized system.

Chris

On Mon, Mar 7, 2016 at 5:36 PM, Jordan Rosen notifications@github.com wrote:

Just returned from HIMSS...FHIR is being heavily promoted by all major vendors.

— Reply to this email directly or view it on GitHub https://github.com/OSEHRA/popHealth/issues/41#issuecomment-193487143.

[lrasmus]

The health-data-standards library appears to have a CCDA importer - so maybe this is easy enough to hook up now?

For FHIR - are you thinking that popHealth would query a FHIR resource for updated data before doing measure calculations? Or that it would accept a FHIR bundle to represent the patient's data?

[Xodarap]

Hi Chris, the HL7 clinical quality informatics workgroup is considering what we are calling "QRDA for data exchange" which I believe is the transmission format you are proposing. You may be interested in joining the CQI calls if you want to have input on this.

[coderdoc]

So that looks like it's for Cypress (?); is the database structure the same (exactly the same!) as for popHealth (or at least with regard to storing the patient data)? Can a parser/importer designed for Cypress import to a popHealth database?

With regard to FHIR, I'm thinking about the ability to consume a bundle of patient data; however, it could also be great if there was a service that an outside EHR could post a CCDA or FHIR to, and get back a quality measures analysis.

Chris

On Fri, Mar 11, 2016 at 4:31 PM, Luke R. notifications@github.com wrote:

The health-data-standards https://github.com/projectcypress/health-data-standards library appears to have a CCDA importer - so maybe this is easy enough to hook up now?

For FHIR - are you thinking that popHealth would query a FHIR resource for updated data before doing measure calculations? Or that it would accept a FHIR bundle to represent the patient's data?

— Reply to this email directly or view it on GitHub https://github.com/OSEHRA/popHealth/issues/41#issuecomment-195563340.

[coderdoc]

Ben- probably my input would be "not another format! make CCDA or FHIR work!". But, I am interested in the calls; I have added them to my calendar.

Chris

On Fri, Mar 11, 2016 at 5:10 PM, Chris Kreis chris1billion@gmail.com wrote:

So that looks like it's for Cypress (?); is the database structure the same (exactly the same!) as for popHealth (or at least with regard to storing the patient data)? Can a parser/importer designed for Cypress import to a popHealth database?

With regard to FHIR, I'm thinking about the ability to consume a bundle of patient data; however, it could also be great if there was a service that an outside EHR could post a CCDA or FHIR to, and get back a quality measures analysis.

Chris

On Fri, Mar 11, 2016 at 4:31 PM, Luke R. notifications@github.com wrote:

The health-data-standards https://github.com/projectcypress/health-data-standards library appears to have a CCDA importer - so maybe this is easy enough to hook up now?

For FHIR - are you thinking that popHealth would query a FHIR resource for updated data before doing measure calculations? Or that it would accept a FHIR bundle to represent the patient's data?

— Reply to this email directly or view it on GitHub https://github.com/OSEHRA/popHealth/issues/41#issuecomment-195563340.

[lrasmus]

The HDS library is used within popHealth for a few different pieces (although you're right, it has its origins in Cypress). popHealth is using this library now though for its C32 import. I think it's just a matter (in theory...) of hooking this into the popHealth patient importer to detect it's a CCDA and then invoke the appropriate parser from the HDS library when it detects CCDA or C32. This is similar to what we've done with our local instance where we've extended the importer to identify JSON files and then import those directly to the MongoDB.

[coderdoc]

Ok thanks Luke, this looks interesting. I'll see if I can find some time to give it a try... I don't suppose the code where you did it with JSON is around somewhere?

On Fri, Mar 11, 2016 at 5:19 PM, Luke R. notifications@github.com wrote:

The HDS library is used within popHealth for a few different pieces (although you're right, it has its origins in Cypress). popHealth is using this library now though for its C32 import. I think it's just a matter (in theory...) of hooking this into the popHealth patient importer to detect it's a CCDA and then invoke the appropriate parser from the HDS library when it detects CCDA or C32. This is similar to what we've done with our local instance where we've extended the importer to identify JSON files and then import those directly to the MongoDB.

— Reply to this email directly or view it on GitHub https://github.com/OSEHRA/popHealth/issues/41#issuecomment-195575236.

[lrasmus]

I just looked at the popHealth code and it looks like the CCDA import might already be in there?

In this same code file, we just look to see (in import_file) if the file is JSON or XML, and then use a custom importer. Pretty straightforward, and am happy to clean up to share if this type of import would be helpful to you.

[coderdoc]

Yes, I think it would be very helpful, and I bet others would find it helpful too. If you do that, please let me know.

Thanks,

Chris

On Fri, Mar 11, 2016 at 5:31 PM, Luke R. notifications@github.com wrote:

I just looked at the popHealth code https://github.com/OSEHRA/popHealth/blob/master/lib/hds/bulk_record_importer.rb#L83-L89 and it looks like the CCDA import might already be in there?

In this same code file, we just look to see (in import_file) if the file is JSON or XML, and then use a custom importer. Pretty straightforward, and am happy to clean up to share if this type of import would be helpful to you.

— Reply to this email directly or view it on GitHub https://github.com/OSEHRA/popHealth/issues/41#issuecomment-195584349.

[coderdoc]

So one more question while I have you guys; why aren't popHealth and Cypress the same project? Cypress imports a standard patient bundle of QRDA Is, calculates measures, exports QRDA Is, EHRs import them, calc, and compare. Theoretically, EHRs could export QRDA Is, import to Cypress as its bundle, and have the measures calculated? This is the same functionality that popHealth provides. Why not one integrated system?

On Fri, Mar 11, 2016 at 5:35 PM, Chris Kreis chris1billion@gmail.com wrote:

Yes, I think it would be very helpful, and I bet others would find it helpful too. If you do that, please let me know.

Thanks,

Chris

On Fri, Mar 11, 2016 at 5:31 PM, Luke R. notifications@github.com wrote:

I just looked at the popHealth code https://github.com/OSEHRA/popHealth/blob/master/lib/hds/bulk_record_importer.rb#L83-L89 and it looks like the CCDA import might already be in there?

In this same code file, we just look to see (in import_file) if the file is JSON or XML, and then use a custom importer. Pretty straightforward, and am happy to clean up to share if this type of import would be helpful to you.

— Reply to this email directly or view it on GitHub https://github.com/OSEHRA/popHealth/issues/41#issuecomment-195584349.

[lrasmus]

Cypress is used to manage the certification process of reporting systems. popHealth started as a reference implementation reporting system, but quickly gained traction as an awesome implementation to use in practice. They have different purposes, but the commonalities you note are in fact shared through some shared libraries. The MITRE folks who developed this did a great job isolating those common components.

[gitouttatown]

What EHRs are actually using PopHealth as a certified eCQM system, in actual production today? -Tom

[coderdoc]

Good question; but, I bet more would if they knew they could. And even if not for certified eCQM, it makes for a great way to test your measures against your own data in your own system (which Cypress doesn't do either). Also I do know at least one woman in the Boston area who has to extract data from Epic to calc CQMs (which actually generates C32s so she might be able to use popHealth without CCDA support). In many cases, people are trying to calculate measures and don't have that ability. Our company gets calls all the time to see if we can calc and submit for them. What is the point of popHealth if it can't be used for CQMs?

I think there might be some companies which have adopted / utilized the code base to offer their own products for calculating CQMs. But I don't know this for a fact; I've just seen similarities.

On Tue, Mar 22, 2016 at 2:04 PM, gitouttatown notifications@github.com wrote:

What EHRs are actually using PopHealth as a certified eCQM system, in actual production today?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/OSEHRA/popHealth/issues/41#issuecomment-199942446

[ewhitley]

As Luke points out, CCDA should be supported by HealthDataStandards (HDS), the (awesome) library popHealth uses to handle the import/export side of things (QRDA I / III, CCDA, C32). I just zipped up a sample CCDA (EMERGE Patient 0) and uploaded it to popHealth - seemed to upload fine. I guess that makes sense considering the original popHealth (way back in MU Stage 1) needed C32.

Now... that's not to say all CDA files will import, though. If it doesn't see the template ID it expects to match a document type (and then fire off the appropriate child importer), then the importer will reject it.

If you take a gander at the HDS code that identifies the valid template IDs (here) and you're not seeing one you expect, that could be the culprit.

When I ported the CCDA/C32 importer/exporter to Swift for CDAKit I took some liberties and adjusted the equivalent section of code to let me say "the heck with it - just try importing the document" because I saw a variety of (to HDS) "invalid" CDA documents. Some lacked US general realm headers, some ONLY had US general realm headers, etc. (read: CDA implementations are highly inconsistent). You can see my additions here. Also - keep in mind each individual child importer process (CCDA, C32, QRDA I) is customized and they're not 100% in sync with each other. Some may not pull data for particular clinical facts. Possibly because there's no concept for that CDA type (EX: smoking status template vs. smoking status in a social history template). If you don't see data you're expecting, check through the per-section template importers by doc type and review.

TLDR;

• HDS is the brains of the import/export operation re: CDA
• A CDA is not a CDA file if you don't have the template IDs HDS expects.

[cjohnsonal]

While the CCDA import for popHealth does seem to work, my research into this has shown that CCDAs don't actually work with the NLM measures. The measures themselves seem to test against fields which aren't supported by CCDAs (At least, none that I've had access to).

[ewhitley]

@cjohnsonal - Totally agree with you. Not that it matters, but I totally agree with you. :)

Warning: rant

I've gone on record with the standards groups, CMS, and the ONC as saying I think QRDA I is a mistake and has actually hurt EMR adoption and value. But QRDA I isn't the real issue - it's just a symptom of the problem.

1) As you point out, the MU 2 patient portal requirement for CCDA export does not address much of the data the measures require. So you have to have two exports. One for patients (in a simplified narrative view) (CCDA) and one for quality/analytics (QRDA I). But the data are different What we're basically saying is "the data we require for your care is less complex / detailed than data we need for determining whether to pay you." That really bothers me. I understand (truly) why you want a simplified data set for care ("just give me the top line so I can continue providing care"), but what bugs me is the inconsistent requirements for the standardized vocabularies and level of detail. Now - this isn't a QRDA I thing, but a larger problem of seeing quality analytics and continuity of care as two separate requirements when the real requirement is "interoperable data."

This stuff is hard to do. Getting your data normalized and then getting it to export - that's not simple. And organizations are struggling with how to approach encoding data so it's interoperable. Don't make it worse by splitting the requirements like this.

Make the requirement simple: You can store the data any way you want internally, but thou shalt import and export (by domain) in (vocabulary x, y, z).

• Problems? SNOMED CT
• Drugs and drug allergies? RxNorm

NOT variability per requirement.

2) In the move from abstracted interpretation of data to calculated/computer-provided data, we didn't pause to think "gee - I wonder if the data we need for all of these crazy complex measures is actually there." We didn't appreciate exactly how much thought, skill, and brain power a clinically-trained abstractor uses to go through a measure and figure out how to gather all of the data elements needed. I don't think it's that easy to discretely capture some of the data required by the CQMs. There's simply too much interpretation involved at this point because there's no way a clinician is going to be able to capture the volume of discrete data required and also provide care. If it were possible, then I'd expect CCDA files patients download from the portal to be much more rich - which they're not.

3) QRDA I has no reason to exist if we have CCDA. Sure, sure - it's all about detail - but that's exactly why it's troubling. Analytics data is more detailed, so you have to export it in QRDA I. Which is a similar (but not the same) format - thereby increasing complexity and cost for everyone. Honestly? Why not just incorporate some of the template information directly into CCDA and settle on one standard? Please? If we can't get the data we need out of the format we're using for shuttling data between care providers, then that should set off alarm bells. We shouldn't introduce yet another format as a work-around. This just seems like two separate workgroups not talking and as a result it's a radical increase in cost for everyone involved - for little, if any, benefit.

4) QRDA I "chicken and the egg" problem. This is the one requirement I just don't fathom - and last I checked wasn't being enforced (so just remove it...). Data for an individual measure should only be exported into a QRDA I file if the patient falls into the measure's IPP. But you can't determine if the patient is in the IPP unless you... run...the... measure? So before determining if you should export the data in a QRDA I file, you'll need to export it into QRDA I, run the IPP portion of the measure, then go back and give a yes/no on whether the QRDA I should be exported. Hrm.

I love that CMS is pushing vendors on this stuff. I love that we're finally moving toward interoperable healthcare. And boy, do I support the ONC 110% as they help us figure out how to do some of this (every single one of the ONC people I've met are just awesome). But - we need to ask "if so many people are asking if we can calculate CQMs with CCD/CCDA and are saying they don't have the required data for the measures, then what's wrong?" I want to see this work. I believe it can work. We need this to work. But to make it work right, I think we have to take a step back, align requirements, and make them link up with some core principles.

[Xodarap]

QRDA I is mostly just a constraint on CCDA templates. If vendors wanted to include these things in their continuity of care documents, they could. Some vendors do.

The purpose of QRDA wasn't to address any technical limitations, but rather legal ones (entities may not be able to legally request a full patient chart, but only a small portion relevant to quality measurement).

Forcing vendors to take everything from their QRDA I and include it in a CCD would be cool though.

[coderdoc]

ewhitley- I could not agree with you more; there should be ONE hierarchical data dictionary (based on numerous standards such as ICD, SNOMED, CPT, LOINC, and rxNorm). It should be possible to represent every element in that dictionary in a hierarchical format (XML/JSON), or relational one (which is ultimately hierarchical anyway). There should be ONE document format to transmit the data. Only need a subset? Then only include a subset. But don't change the format, relations, structure, or codes or create a new document.

Ben, a few messages back you asked me about joining a call regarding creation of another format; I jumped on to one of the calls (a bit late!), and it was a few people discussing data points for surgical procedures. So, maybe wrong call. Is there a specific call/group you recommend? I'll try to get on some time.

cjohnsonal; per above I am at some point going to see if I can get some CCDAs imported, with relevant data points, and see if I can get any measures to run...

Chris

On Wed, Apr 27, 2016 at 12:11 PM, Ben West notifications@github.com wrote:

QRDA I is mostly just a constraint on CCDA templates. If vendors wanted to include these things in their continuity of care documents, they could. Some vendors do.

The purpose of QRDA wasn't to address any technical limitations, but rather legal ones (entities may not be able to legally request a full patient chart, but only a small portion relevant to quality measurement).

Forcing vendors to take everything from their QRDA I and include it in a CCD would be cool though.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/OSEHRA/popHealth/issues/41#issuecomment-215134140

[cjohnsonal]

Just yesterday I was finally able to get some imported CCDAs to work, but to do so I had to manually add an encounter field; it seems the test data include this, but for some reason the records we're working with don't, so the lack of functionality may be vendor-based. Even with adding the encounter, though, the metrics wouldn't show on the dashboard, just the individual measure pages, so I still need to take a closer look to figure out what's going wrong.

[gitouttatown]

Now that 5.0 is out and is 2015 certified (kudos on that!) I have to ask again what I asked over a year ago: what EHRs actually use popHealth?

And add to that, does version 5.0 allow populating the popHealth DB with CCDA files or is it still dependent on the now obsolete CCR and C32 formats?

[petercyli]

We didn't perform any tests associated with CCDA import for v5.0. It would be up to the members of the community to check if the CCDA import continue to work as is. If you need specific CCDA support, you can work with the Alabama Medicaid team to add them to the popHealth.

We don't keep track of EHRs that uses popHealth, so I can't help you with that information.