There is a rush in connecting, sharing data between various healthcare systems. Systems developed earlier did not know or care about standards like HL7, DICOM, HIPPA etc. So the manager one morning decides make it a 'complaint'. That sometimes might be less to do with the applications' interoperability but more of a tag that the marketing department likes to see on it. We were asked like this -
I sort of need consulting and guidance as to which HL7 messages I should and can provide. We don't have any HL7 expertise in house. The goal is that I want to be able to say to business partners "Yes, we are HL7 compliant" - that is the goal, but there is actually no particular "target system" nor "target use" in mind at this point. So, how can I proceed? Perhaps this is a two-phase project: firstly, I want to get our application to a point where I can say it is "HL7 compliant". Then, "Phase 2" will occur the first time we actually land a customer who wants to use the HL7 component of our product - only at that time will be know the details of what sort of integration is needed. Does this approach make sense?
So if you are looking for a start to make your software a HL7 complaint, please read this from HL7.org - http://www.hl7.org/about/FAQs/index.cfm Expand the 'Training and Certification', and read 'My company does X, and we need to become HL7 compliant, what do we need to do?'
HL7 basics
If you would wonder what is HL7, is it a device or a software. The answer is, HL7 is a set of best practices on how your medical data should be organized; and how that data could be shared between different healthcare systems on demand. A very short answer also could be - HL7 is a very specific structure of data in a file format or database, that may contain, patient demographics, medical exam results, clinical records etc.
HL7 messaging
This uniform data structure help removing the data ambiguity between various independent healthcare systems. Two unknown systems may have their own way of organizing data, but if they are HL7 complaint, they would be able interpret, exchange data between them. For example, your in-house EMR or a transcriptionist might need to send a claim to a 3rd party billing system. Both the systems may have their own way of keeping data, but they can easily exchange data if they were HL7 complaint. (scanning, uploading/faxing bills etc. are the old ways)
HL7 messaging/data structure could defer from practice to practice, like clinical HL7 messages won't be same as EHR HL7 messages.
You can also subscribe from here, https://www.hl7.org/store/index.cfm to find out what set of HL7 messages your software should be able to send/receive to become a HL7 compliant. The most common type of system that goes for HL7 compliance is the electronic health record software. For correct set of HL7 messages for your system, consider hiring a HL7 development company such as ours to implement and develop a HL7 interface. Read more about our HL7 interface development expertise and maybe, get in touch with us :)