CCD HITSP/C32

[James Cobane]

Has anyone had any experience dealing with CCD (Continuity of Care Document) transactions in Cloverleaf?  Any information would be appreciated.

Thanks in advance.

Jim Cobane

Henry Ford Health

Topic

[Mark Thompson]

Jim,

I got these from Tech Support last week:

“Version 3 of HL7 is implemented as XML.  Beginning with Cloverleaf 5.4.1 you will find definitions in the integrator/formats/xml directory referred to as CDA.”

… and …

“You will need to copy these in to your site xml directories and compile them treating them like any other xml implementation.  If you have not done an XML interface before I would encourage you to get implementation assistance.  There is a lot to learn.  I would also encourage you to do these interfaces using the latest cloverleaf version (5.7) because there have been a lot of improvements in XML handling along the way.”

We’re doing quite a bit of XML (but no CDA) on 5.6 and planning our 5.7 upgrade.

- Mark Thompson
HealthPartners

[James Cobane]

Mark,

Thanks for the info.  This is great!

Jim Cobane

Henry Ford Health

[Darren Tomlinson]

James, have you had any luck with this?  i see what mark referenced, but i’m still not too sure what to do with it all.

Can i ask how you are trying to implement this?  Our hospital is working with the DOD and trying to query Allscripts to get out the information requested.  Allscripts cannot offer us this ability, so we are trying to do this all in-house.  We’re not sure where to begin really.

[Keith W. Boone]

I’ve been there several times with multiple engines over the past few years.

I use the same process each time:

1.  Convert the HL7 Version 2 message to HL7 Version 2 XML (you can download the DTDs or schemas for V2 XML formats from the HL7 Web site).  I’ve discovered that the DTDs work better than the Schemas.

2.  Generate the CCD via an XSLT transform of the V2 XML message.

V2 Segment — CDA Component

TXA -> Clinical Document Header

PID -> patientRole

PV1 -> componentOf/encompassingEncounter

OBR -> sections

OBX -> components of a section

3.  You may need to run two passes, first to generate CDA Level 3 structures using the CCD, then use those to generate the narrative text.

I use a fairly simple Java UPOC to support the XSLT transform in the version of Cloverleaf I’m using but I understand later versions of Cloverleaf supports XSLT natively.

[Hope Rolens]

From reading this post, I am of the understanding that using Cloverleaf version 5.7 to pass CCD documents between systems has been done by other Lawson clients.

But I was wondering if using Cloverleaf 5.7 to move CCD data between other ‘CCD certified’ systems meets the certification requirements.

I’ve not been able to find a definitive answer (or at least an intelligible answer) so far.  Hoping someone from this forum could help.

Thanks,

Hope Schnelten

Hospital Sisters Health Systems

Springfield, Illinois

[Daniel Lee]

Good luck getting clarification on the meaningful use requirements.

[Hope Rolens]

Daniel,

thanks for the reply.  If by some miracle I come across a definitive answer on the use of interface engines for CCD documents for future stages, I’ll post it on Clovertech.

[Peter Heggie]

We have to take a CCD in an XML file from one system and send it to another system in HL7 format. The entire XML is to be encoded in base64 and put into an OBX#5. We also need to value a minimum set of fields in the surrounding HL7 segments, such as encounter number, document ID, etc.

I’ve setup an XML to HL7 xlate, using as input an XML package I created by copying the HL7_CDA_2.0-xsd schemas supplied in the CL root into a /formats/xml/HL7_CDA_2.0-xsd directory I created and running the XML Packager compile on that copy.

I have created and successfully tested the necessary COPY statements in the xlate, copying from XML fields to HL7 fields, except for the most important part – the entire XML document that is to go into OBX#5. I can’t seem to find a node on the input side XML that represents the entire XML. I tried using the ?xml.&standalone attribute but that comes up empty.

I don’t want to create my own version of the xsd – this is an HL7 standard document (thank you Cloverleaf for bundling it), but it seems like there is no other way to access it.

Does anyone know how to access the entire XML as an input value? Or is there another xsd I can package? It seems like there are several schemas bundled with Cloverleaf that can work with CCDs.

Peter

Peter Heggie

[Peter Heggie]

I found that the standalone attribute is used when there is an internal DTD and indicates how validation and external references are to be processed. So I’m back to my question of how to access the entire XML content in one COPY operation.

Peter Heggie

[Jim Kosloskey]

Peter,

My take would be this:

You will have to place the entire message either in a Tcl global in the pre-route UPoC (then reference that global inside an xltp type proc).

Or…

In the pre-route place the message in the metadat USERDTATA field (make it a keyed entry and follow all of the rules regarding preserving USERDATA before modifying. Then in an xltp proc inside your Xlate extract the message from USERDATA (using the key you set in the Tps proc).

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Peter Heggie]

Thanks Jim, I’ll try that.

Peter Heggie

[Peter Heggie]

That worked well – thank you.

Peter Heggie

[Jim Kosloskey]

Peter,

Which method did you choose?

If the global route then just be aware starting with 5.8 Cloverleaf there could be considerations regarding use of globals inside Xlates that are set in the pre-route. I believe it is related to the capability to multi-thread the Xlate thread.

Of course in either case it is no bargain to essentially occupy duplicate resources somewhere for what can be an immense message.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Peter Heggie]

Yes – I found your earlier threads on saving data between pre-route and xlate, where the 5.8 change regarding globals (may not be a good thing to rely on) was noted, so I used the second method – storing the content in a USERDATA keyed list item. I copied Russ Ross’s xltp that extracts a keyed list item from USERDATA, and added logic for base64 encoding and deleting that key & value from USERDATA after extracting the value, to reduce the storage needed. But yes, I hate to store all that data a second time. Maybe I should ask support for a customized xsd or .ocm file that provides a node that references the entire content?

Peter Heggie

[Mike Kim]

We use the HL7Connect interface engine for CCD/CDA.  It’s much easier.  Basically, you can paste in an existing CCD/CDA and then, wherever you want variable data, from an HL7 V2 message or from a database, you just embed code.  Since these Clinical Documents are mostly boilerplate, it works well.

[Peter Heggie]

It looks like there is a lot of overlap between Cloverleaf and HL7 Connect as far as capabilities, with the differences being in the implementation and development tools and languages.

The Intelligent Broker add-on to Cloverleaf can provide web service hosting and invocation, and interfaces to CLoverleaf threads, and the next version will be much more integrated with the core product. However, an alternative may be Windows IIS (especially if an IIS server is already available) plus .Net Visual Studio to create the web services and TCP/IP interface to Cloverleaf, as well as .Net classes to manipulate CCA documents. The latter may be more cost effective and as always the question of organizational skill sets is an important consideration.

Peter Heggie

[Author]

Replies