CCD and HL7 V3 / V2 - hl7

My company is going to be an HIE and we are figuring out how to exchange our information with other systems. We are located in USA and I see that the current common standard is HL7 V2. Hl7 V3 is not backward compatible to HL7 V2. These are the transactions that we are planning to implement:
o Discharge Summaries
o Progress Notes
o Lab Results
o Procedures/Orders
This whole thing is complicated and I am trying to figure out using bits and pieces of info scattered in the net. So here are my questions:
Should we look at HL7 V3 or V2 implementation?
Are CCD and HL7 V2 compatible? Most of the documents I saw from HITSP talks about HL7 V3.
Where can I find an exhaustive list of data fields which are required for all the transactions above? Is it defined by HITSP?
Do the fields defined for each transaction change depending on whether we go with HL7 V3 or V2?
Any help will be much appreciated!

If you're going to be an HIE, you're going to need to handle both HL7 v2 and v3. My experience is that almost all "real life" data transmission is v2 (I think this is probably because most systems capable of v3 transmission also allow v2 formatting, whereas the older systems cannot handle v3, but this is just speculation). There's a very superficial overview of the core differences between v2 and v3 here, which talks a bit about what fundamental changes are being made besides format (delimited vs xml)
The second part of your questions doesn't really have a definitive answer, and ties in with your fourth question. CCD can be HL7v2 compatible, but it's a lot more difficult and relies on the sender and receiver both having a common understanding on a number of issues (hl7v2 is a very loose "standard"). Here's HL7standard.com's thoughts on the subject:
The short answer is "yes" with the long answer being "it depends."
There are different levels of CDA/CCD documents. It probably would be
possible to create a Level-1 CDA document from an HL7 v2 message,
assuming you had a fairly robust HL7 v2 report of some flavor (MDM or
ORU type of message most likely).
It would be harder to take an HL7 v2 message and convert it into a
Level-2 or Level-3 CDA document. More data is required in those
formats, and that data needs to be structured, not just free form
text.
The CDA is based on the HL7 v3 RIM, and compliant CDA documents will
follow that data model. Mapping from one data model to another can be
challenging.
All CDA documents need to have a responsible party or person who
'signs' the document. At a minimum, the HL7 v2 message would have to
have this information.
Converting a CDA document into an HL7 v2 message is possible, but you
run the risk of losing the 'context' of the data that is in the
original document if it is a highly structured Level-2 or Level-3
document. If the CDA contains nothing more than a textual report and
some patient demographic information, then it can be converted into a
comparable v2 message.
For getting a full list of fields, I'd just purchase the full HL7 standard... and maybe have a look over at bluebuttonplus.org... though keep in mind that v2 can result in some confusion, as message sub-segments aren't always consistently used between different actors. Anyway, I don't think that there are clean answers to most of what you're asking, but at the very least you will really need to handle both formats. I'd also throw in that you may want to look at a product like Mirth or InterfaceWare to handle some of your parsing and testing.

You'll definitely want to take a look at HL7.org. The HL7 standards are now available for free, and a large part of it is licensed at no cost. As far as HL7 version, 2.5.1 seems to be the standard for the v2 space. As stated in the other answer, you'll want to support both V2 and V3 HL7.
If you are looking in to sending the CCD, looking at the same HL7 site search for QRDA, the Quality Document Reporting Architecture, an XML HL7 standard for the transmission of the CDA.
Two other notes on this, you'll want to look at the emerging discussions around QRDA I and QRDA III that are taking place now with ONC, and the revised standards for the CCDA.
Here's a direct link to the, I believe, most recent CDA standard on HL7.org
HL7/ASTM Implementation Guide for CDA Release 2 -Continuity of Care Document (CCD®) Release 1
Finally, you will need to have conversations with the major EHR players such as Epic, Cerner and Meditech. They'll need to be on board with your solution and can guide you through the implementation process. In addition to that, they will need to know how best to set up their systems to talk to yours so they can guide their clients. Without this I'm afraid you'll get no traction.

Related

Has anyone written out the grammar in BNF for the Internet Printing Protocol Collections record described in RFC3382?

I am having a little trouble generating the Collection records described in Internet Printing Protocol definition RFC3382. Has anyone written out the grammar in BNF?
It's hard to say! I frequently research the internet about IPP and have not come across any work related to IPP and BNF (Backus-Naur-Form) so far.
I guess the PWG IPP mailing list would be a better audience for this question. Most ipp implementations don't use a scanner or parser to deal with ipp messages. I assume you implement an ipp server and have covered the ipp parsing already.
Sometimes it is a good approach to capture an ipp message (response) of a real printer and have a look at its byte sequence. On request (personal mail) I can provide such a response in binary format (including a media-col-default and media-col-database attribute)
I got an answer from the Printer Working Group (PWG) site. The short answer is that a RFC-in-progress has a more precise grammar for Collections.
From Michael Sweet:
There is an updated ABNF grammar in the upcoming RFC 8010 (which
replaces RFCs 2910 and 3382) along with better examples that might be
of some help. Here is a link to the authors' review copy (it should
be published very soon!):
https://www.rfc-editor.org/authors/rfc8010.txt
Sections 3.1.6 and 3.1.7 cover the encoding of the collection
attribute and its member attributes, respectively.
FWIW, the "design" of collections in 3382 was done specifically to
make them look like a 1setOf attribute with a mix of values so that
existing clients/printers could more easily deal with them. In
practice this makes supporting collections a little more difficult
(and the encoding of collection values a little more verbose) than is
ideal... :/
(Mr Sweet, I apologize for redistributing your information without consulting you)

How i know when a web site is using RDF?

How do I know when a web site uses an RDF ?
For example , I know that eBay and Amazon uses RDF because I've read in many articles, but as I know it in practice ?
In practice, there is currently no single standardized way for websites to "advertise" their use of RDF. You find out by them informing you about it in some fashion, e.g. by them publishing a link to API documentation that describes how they use RDF, or indeed by writing an article about it, so pretty much the same way you find out about any REST API / web service. Of course, in the case of RDF/linked data you are often helped by the fact that other datasets you already know about may be linking to the new source, thus making it discoverable.
There are some attempts at defining more standardized mechanisms for 'advertising' a website's linked data use. The W3C VoID specification is the closest thing to a standard in that regard: it provides a vocabulary for publishers to describe the data and access mechanisms they offer, and it also gives pointers on how to make things discoverable. Unfortunately, it is not (yet) very widely adopted.

HL7 version 3 parsing

I was parsing HL7 version 2.x messages through HAPI. Now I want to parse HL7 version 3 messages, which are in XML format. HAPI does not support HL7 version 3, so how can I do this?
HL7 version 3 is essentially XML-formatted HL7 data. As such, you could use any old XML parser. That said, you would have to build the intelligence re: segments etc... in yourself.
It does, however, appear that there is an HL7 v3 Java Special Interest Group, which has developed an API at least for RIM.
Another option would be to look at an integration engine. An open source option here is mirth. Mirth is a interface integration engine. It is a separate product - not a library you would integrate with your own. It can, however, take over the heavy lifting of converting HL7 to something more useful in your application - a Web Service call, a database insert, a differently formatted file (pdf, edi, etc).
Mohawk College publishes a Free and Open Source (FLOSS) API Framework for HL7 version 3 messaging and CDA Document processing called the "Everest Framework".
This framework is available for Java and .NET and comes with extensive examples and documentation on how to use HL7v3 messaging.
You can download the framework at (https://github.com/MohawkMEDIC/everest).
Support is also available via the GitHub project page.
This framework was developed through grant funding provided by the Natural Sciences and Engineering Research Council of Canada (NSERC) and Canada Health Infoway.
I used HL7 Java SIG some time ago (2008), but it is very easy to 1. create your own parser from the schemas using JAXB (Generate Java classes from .XSD files...?), or 2. create your own parser from scratch (I would suggest to use Groovy XMLSlurper http://www.groovy-lang.org/processing-xml.html).
You were asking for a link to the official parser for HL7v3 (go to the section under "v3 Utilities", I'll admit it's not easy to find but here it is:
http://www.hl7.org/participate/toolsandresources.cfm?ref=nav
They have some examples and data files to test with as well.

Is there a more modern implementation of CORBA?

I'm figuring that CORBA is considered a legacy technology that just refuses to die. That being said, I'm curious if there are any known standards out there that are preferred (and are also as platform independent.)
Thoughts? TIA!
Many organization are moving to WebServices and the open standards relating to them (HTTP, WS-*) as alternatives to Corba.
This article provides a comparison of the two technologies and offers some recommendations on when to use which.
If you really care about platform independence and protocol standardization - then the WS-* standards are something to look into.
There is now a state of the art modern CORBA implementation using C++11, TAOX11. This uses the new IDL to C++11 language mapping. For TAOX11 see the TAOX11 website. TAOX11 is supported on a wide range of platforms and compilers.
I have recently tried Google Protocol buffers, they seem rather similar to CORBA by design (some kind of IDL with compiler, binary compact messages, etc). It is probably one of the many possible successors.
Web services are good for the right tasks but creating and parsing messages needs more time and text based messages are more bulky than binary ones. REST API with JSON looks like a good solution where binary protocols do not fit well.
ICE from ZeroC aims to be a "better CORBA".
Unfortunately their licensing terms are crap (at least last time I checked with them), as they do not sell developer licenses but only (roughly) per-installation terms.
It is offered via GPL license too, if you can live with this.

Need help on Beginning HL7

hI
Can anyone please guide me to Creating HL7 Version 3 messages for the first time. I need to understand the design of XML based HL7v 3 message. I want to design an interface engine in Java. Have tried to find.. but cannot see anything for beginners.
Please help
HL-7 documentation has to be purchased from hl7.org. They control copyright and so legal free copies aren't available AFAIK.
If you feel thrifty and are willing to work out some of the information yourself, the HAPI project might be a good place to start. If you look at the code you can see how some of the different segments are represented.
There's a tool I've been using lately that helped me on that. It's called HL7 Soup which is a HL7 Viewer.
It's advantage over other products I used is it's easier to understand messages and its structure, which helped me learning lots about HL7.

Resources