4 ms·
The HL7 specification defines specific message segments for specific kinds of clinical data. It defines the events which should trigger different types of messa
by absconditus 17y ago
The HL7 specification defines specific message segments for specific kinds of clinical data. It defines the events which should trigger different types of messages. It defines a minimal protocol to be used to transmit messages (which nearly everyone uses). It is not at all analogous to JSON nor XML. HL7 3.x isn't just XML-ish; it allows the use of standard XML (in addition to the classic delimited format).
Again, I don't know of any hospital system which doesn't offer one or more specific HL7 interfaces (ADT, results, billing, etc.). It is very common for hospitals to have clinical document repositories which accept multiple formats.
While I agree with your general sentiments about the state of the industry, I don't believe the problem to be a lack of standards or opportunities for integration. Additionally, the incentives you speak of will happen at the end of the year. See my comment elsewhere about CCD/CDA (CDA is part of the HL7 standards). ARRA funds will be available at the end of the year for systems which implement HITSP standards (I'm oversimplifying a bit).
- absconditus 17y agoI wanted to add that I believe the industry's biggest problem to be a lack of software development talent. No top MIT graduate is torn between working for Google and working on automating the paper workflow of a hospital. Although there are several standards available for specific types of information exchange they are rarely implemented properly. They are also poorly designed. The CCD standard is quite atrocious.
- siculars 17y agoThat speaks to the intolerable nature of working in one of these bureaucracies. I could not agree with you more. There is a lack of talent in this field and a lot of it has to do with the leadership. Decision makers not only do not understand the potential of suggested solutions but also are unwilling to take the risk on homegrown or non-vendor supported solutions. In doing so they alienate the talent that works for them and forces them to look elsewhere. I'll outline a hypothetical problem... Large institution passes on homegrown solution (no vendor support problem) buys large commercial system. Large commercial system takes years to integrate into med center culture and legacy systems, problems abound. Innovative students/professors/physicians/staff suggest enhancements to better... everything and do things the system does not and was not intended to do. None of this gets done due to short sighted, risk averse administration and lack of integration support from vendor. Nobody at med center knows how to decipher the gargantuan database schema or access their own data (programmatically) outside of the commercial gui. Frustrated talent walks out the door. Rinse, repeat. Now, if these systems came with documented bidirectional open api's then people could just do whatever they wanted (with appropriate access controls, duh). If someone wants to write a new and better client for Twitter they do not have to ask twitter for permission, they just do it. Although vendors do use HL7 for ADT related activities, there is way more to a modern day EHR than that. And before people start beating me up about protected HIPAA data, simply control access tokens to pump fake data during development. Speaking to your other point about HL7, it's inherent standards, CCD/CDA and HITSP, I agree, there are certain proposed solutions but how are they actually employed? Whatever incentives ARRA is offering they just are not enough or geared in a fashion that may make a dent, imho. I don't know if you can tell, but I am highly disillusioned as to the state of the state in this industry. Best as I can tell leadership in this area will come from out of the way, non academic, regional for profit hospital conglomerates that will force change to drive profit. Once the rest of the field sees their results they may join in in any standards those leaders employ. Hopefully they will include the bidirectional open api concept. I'm not holding my breath. EDIT: When I say "if these systems came with documented bidirectional open api's" I am speaking to your point re "they are rarely implemented properly". These existing api's may get the job done, but they are rarely implemented and if they are, they are certainly not implemented properly. Perhaps that should be incentivized as well?