It appears to me that major health care institutions are (or already have started) implementing the import capability using the CCD format.  Some do not plan to support the CCR format.  The hospital in my area and the associated doctors has started using RelayHealth which allows for the import and export of CCD formatted XML files.  I was so pleased to find that RelayHealth had a plug-in that would create a CCD document (although a little awkwardly).

I used the plug-in to create the XML document and imported it into RelayHealth.  The result was disappointing.  While one data section was imported the others were not.  Upon talking with the support people at RelayHealth, they stated (after they reviewed the file created by HealthFrame) that the import file must comply with the CCD standard HITSP C32 Version 2.3 to work correctly.

It is imperative to be able to import records from HealthFrame into these systems and it is requested that the Plug-in be updated so as to support the latest CCD standard.  If agreed I would like to see the option to be able to directly save the created XML document to a filename and location of the users choosing.

Please let me know.

Rob,

THANK YOU for your feedback in this extremely important topic.  It is very exciting to see hospitals such as the ones in your area, starting to accept patient-initiated exchanges (import/export) of electronic health records.

Our CCD support complies (i.e. 'no errors') with the CDA R2 format rules, as tested using the NIST validation tool set: http://xreg2.nist.gov/cda-validation/validation.html.  This is also known as the HL7 CDA R2 (with no extensions) version, whereas the version you mentioned, includes HITSP/C83 Extensions.  You may want to inquire (we will also on our part) as to whether the RelayHealth tool supports using CDA without extensions - maybe there is a configuration setting for that.

It is also interesting that the NIST validation tools support testing for HITSP C32 Versions 2.1, 2.4, and 2.5 - but not 2.3...  We will need to investigate whether independent verification for 2.3 will be possible.  Maybe RelayHealth should also consider upgrading their support to a version that is supported by NIST's suite (e.g. 2.4).

We will look into upgrading our plug-in, and we would hope to perhaps continue to count on your feedback as to how the integration works with RelayHealth?

Thank you again for your feedback,
Support Team

Thanks for the great support and the information.  I have forwarded your comments on to RelayHealth.  I will definitely keep you informed of my efforts with RelayHealth to resolve this import problem.  If you wish to contact RelayHealth their support number is 1-866-735-2963 Ext 1.

I created a new CCD file from HealthFrame and ran it against the NIST validation tool selecting the CCD option.  The result is as follows:

CDA R2 Errors: No errors!

CDA R2 Warnings: No warnings!

CCD:

Schematron Report

Schematron schema for validating conformance to CCD documents

A problem observation SHOULD contain exactly one Observation / effectiveTime, to indicate the timing of condition (e.g. the time the condition started, the onset of the illness or symptom).

Location: /ClinicalDocument[1]/component[1]/structuredBody[1]/component[2]/section[1]/entry[12]/act[1]/entryRelationship[1]/observation[1]

Test: count(cda:effectiveTime)=1

Upon further investigation into the NIST validation error, I discovered that HealthFrame allows for a blank entry for the Start Date of a Condition.  This causes the file generated with the CCD plug-in to not include an 'effectiveTime' element for the condition.

Proposed Solution:  Include a null 'effectiveTime' element (e.g. <effectiveTime/> ) in the CCD file when a Start Date is blank.  This solution should be considered for any element where an entry is required by the standard.

Add the creation of the CCD xml document to the Export PHR function.

RxNorm values are being prefixed with ‘RX1’.   This is preventing some EMR systems to reject these entries upon import.

Further testing after the April, 2010 release of RelayHealth (RH) has shown that the statement by RH's support staff that the CCD (to be imported) must be constrained by HITSP C32 Versions 2.3 was NOT correct.  The CCD created by HealthFrame will work with RH without this constraint.  The initial problem was RH's failure to support the RxNorm coding for medication which is a requirement of the standard.  As of the April release, they now support the RxNorm coding but are having translation/lookup problems in this area.  In addition, their limited support of SIG elements brings into question the usefulness of this area in RH.

I was fortunate to be introduced to the IT Project Manager associated with the RelayHealth implementation at my hospital.  She is very receptive in receiving my experiences in using RH and will be using my feedback in her implementation meetings.

I will provide updates when additional information is available.

It appears that there is a problem when trying to create a CCD from large CCR files.

The error message states that "the timeout period expired."

I have tested this problem on two computers and the results are the same.  The test is being performed using the sample PHR for Jose Gonzalez.  The CCR file size for this patient is 674kB.

If anyone can confirm this problem, please reply with your comments to this Subject.

This is a known problem with HealthFrames CCD support.

Really - its two problems - which is why there is no easy fix.

The first 'problem' - is that when running OpenHealthService plugins - HealthFrame has a TIMEOUT period. Since OpenHealthServices are plugins which anybody can write, HealthFrame cannot be sure if they take a long time that they are not hung, so it times out after 2 minutes.

There is an open bug report to track this issue, and we will probably add a configuration setting to HealthFrame letting users change the default OpenHealthServices timeout (http://bugzilla/show_bug.cgi?id=627).

The second problem is that the current CCR -> CCD conversion code we have runs as an OpenHealthService plugin, and it is slow. Really - the problem is that it is slow. We have another bug report to track the issue of speeding up CCR -> CCD conversion, but that bug report is currently LOW priority (http://bugzilla/show_bug.cgi?id=628). You are the first to have complained. If you consider it serious, please let us know, and we will consider escalating the issue.

Finally - a workaround - of sorts. Run on a faster computer. There is (essentially) no limitation on how LARGE a CCD you can create, except that the transformations get slower as the files get larger. If you try your transformation on a faster computer, it may succeed. I've tried exporting that particular file on a 3 year old laptop, and it was fast enough (took about 45 seconds).

Thanks for the the fast reply.

One of the main features of HealthFrame (HF) is its capability to import and export standard health record formats.  So I do think that a resolution is needed so that CCD can always be exported regardless the size of the data.  Hopefully this can be done with the release of HF Ver 3; if not, then HF Ver. 3.1.  There is a change request that the CCD creation be moved to the export function.  Moving this feature to an export function, instead of a plug-in, should help.

I did try the CCD creation on a third system and the creation was successful.  So the CPU speed is a major factor in the ability for the report to be created before the two minute time-out is reached.

Test Results
Desktop     Pent 4  2.6GHz, 1.5GB             Failed
Workstation Pent D  2.8GHz (OC 3.2GHz), 2GB   Passed