I am going to implement a generic HMIS with true implementation of HL7. I have studied all the advantages and disadvantages of both versions of HL7 i.e v2 and v3. But still the confusion exists that which version is better to go with implementation either it is v2 for its stability or v3 for its plug and play compatibility. Need your opinion.
The HL7 is the organization but also is a set of interoperability standards. It means it is not a function in your system that operates on its own, it is a way that your system communicates with other systems. So the interface that you need to implement in your system - HL7v2 or HL7v3 or HL7 FHIR – is actually dictated by your counterparts.
For example, if you are in US, most likely you'll end up with HL7v2 for messaging, HL7v3 CDA for documents (better know as a separate C-CDA standard) and HL7 FHIR for SMART initiatives. (Let's assume we are not talking about IHE profiles with "v3" suffix.) For Canada and UK it will be the same with the only difference that these countries are using HL7v2 and HL7v3 for messaging.
I would like to answer your question based on Implementation and Data consumption.
HL7v2 is pipe delimited and v3 is of XML, FHIR comes in JSON and XML flavors. Before discussing advantage and disadvantage, it is essential to understand how the end system consumes data. What provision they have, and based on that you can proceed further.
If this question is regarding how efficiently all patient data can be captured in a message format? . I will go with both V2 and V3. V3 is much more standardized, gives more specifications and descriptions. V2 is also has HL7 specific standards for it, if you think that specific message format of yours (ADT/ORU/DFT) lacks specific features to capture, you can use Z-segment or NTE. V3 CDA standards makes sure (upto what I have used), covers most information with its specification itself.
For (Eg:consider CDA standards) Based on the needs CDA can come with its own flavor, as of HL7 standards there are separate Progress notes C-CDA, Procedure notes C-CDA, Transition of Care C-CDA, Diagnostic Imaging Report C-CDA and so on.
Related
Events in an event store (event sourcing) are most often persisted in a serialized format with versions to represent a changed in the model or schema for an event type. I haven't been able to find good documentation showing the actual model or schema for an actual event (often data table in event store schema if using a RDBMS) but understand that ideally it should be generic.
What are the most basic fields/properties that should exist in an event?
I've contemplated using json-api as a specification for my events but perhaps that's too "heavy". The benefits I see are flexibility and maturity.
Am I heading down the "wrong path"?
Any well defined examples would be greatly appreciated.
I've contemplated using json-api as a specification for my events but perhaps that's too "heavy". The benefits I see are flexibility and maturity.
Am I heading down the "wrong path"?
Don't overlook forward and backward compatibility.
You should plan to review Greg Young's book on event versioning; it doesn't directly answer your question, but it does cover a lot about the basics of interpreting an event.
Short answer: pretty much everything is optional, because you need to be able to change it later.
You should also review Hohpe's Enterprise Integration Patterns, in particular his work on messaging, which details a lot of cases you may care about.
de Graauw's Nobody Needs Reliable Messaging helped me to understan an important point.
To summarize: if reliability is important on the business level, do it on the business level.
So while there are some interesting bits of meta data tracking that you may want to do, the domain model is really only going to look at the data; and that is going to tend to be specific to your domain.
You also have the fun that the representation of events that you use in the service that produces them may not match the representation that it shares with other services, and in particular may not be the same message that gets broadcast.
I worked through an exercise trying to figure out what the minimum amount of information necessary for a subscriber to look at an event to understand if it cares. My answers were an id (have I seen this specific event before?), a token that tells you the semantic meaning of the message (is that something I care about?), and a location (URI) to get a richer representation if it is something I care about.
But outside of the domain -- for example, when you are looking at the system as a whole trying to figure out what is going on, having correlation identifiers and causation identifiers, time stamps, signatures of the source location, and so on stored in a consistent location in the meta data can be a big help.
Just modelling with basic types that map to Json to write as you would for an API can go a long way.
You can spend a lot of time generating overly complex models if you throw too much tooling at it - things like Apache Thrift and/or Protocol Buffers (or derived things) will provide all sorts of IDL mechanisms for you to generate incidental complexity with.
In .NET land and many other platforms, if you namespace the types you can do various projections from the types
Personally, I've used records and DUs in F# as a design and representation tool
you get intellisense, syntax hilighting, and types you can use from F# or C# for free
if someone wants to look, types.fs has all they need
We are currently in the process of evaluating FHIR for use as part of our medical record infrastructure. For the EHR data (Allergies, Visits, Rx, etc..) the HL7 FHIR seems to have an appropriate mapping.
However, lots of data that we deal with is related to personal Fitness - think Fitbit or Apple HealthKit:
Active exercise (aerobic or workout): quantity, energy, heart-rate
Routine activities such as daily steps or water consumption
Sleep patterns/quality (odd case of inter-lapping states within the same timespan)
Other user-provided: emotional rating, eating activity, women's health, UV
While there is the Observation resource, this still seems best fit (!) for the EHR domain. In particular, the user fitness data is not collected during a visit and is not human-verified.
The goal is to find a "standardized FIHR way" to model this sort of data.
Use an Observation (?) with Extensions? Profiles? Domain-specific rules?
FHIR allows extraordinary flexibility, but each extension/profile may increase the cost of being able to exchange the resource directly later.
An explanation on the appropriate use of an FHIR resource - including when to Extend, use Profiles/tags, or encode differentiation via Coded values - would be useful.
Define a new/custom Resource type?
FHIR DSTU2 does not define a way to define a new Resource type. Wanting to do so may indicate that the role of resources - logical concept vs. an implementation interface? - is not understood.
Don't use FHIR at all? Don't use FHIR except on summary interchanges?
It could also be the case that FHIR is not suitable for our messaging format. But would it be any "worse" to go FIHRa <-> FIHRb than x <-> FIHRc when dealing with external interoperability?
The FHIR Registry did not seem to contain any User-Fitness specific Observation Profiles and none of the Proposed Resources seem to add appropriate resource-refinements.
At the end of the day, it would be nice to be able to claim to be able to - with minimal or no translation, ie. in a "standard manner" - be able to exchange User Fitness data as an FHIR stream.
Certainly the intent is to use Observation, and there's lots of projects already doing this.
There's no need for extensions, it's just a straight forward use. Note that this: " In particular the user fitness data is not collected during a visit and is not human-verified" doesn't matter. There's lots of EHR data of dubious provenance...
You just need to use the right codes, and bingo, it all works. I've provided a bit more detail to the answer here:
http://www.healthintersections.com.au/?p=2487
Is there any difference between HL7 USA and UK standards ? If its there then what are those ?
I'm not aware of any country-specific HL7 features neither did Google query site:hl7.org country specific reveal something eye striking. But it does not mean there are no differences
I guess your best bet would be to narrow your question down to a particular set of messages, register as member at hl7.org and ask this question through their internal mailing list (Even better best bet might be to talk to some friendly competitor and ask for the lessons learned)
In our country-specific HL7 community the membership is also paid, but the benefits of becoming a member are close to 0 from the developer's perspective. It's prestigious to be a member and it looks good on the business card. But all you get is access to downloadable specifications (but most of them are free for about a year anyway)
In the software I was working with we were exchanging only very small set of hl7 messages, namely: ADT^A04, ADT^A05, ADT^A08, ADT^A18, ADT^A23, ADT^A34, ORM^O01 and ACK in 2 different countries, considering adding 3rd country, without any country-specific features needed, except the convention used for identifying patient with his/her security number. The number format was country-specific but it was handled by upper software layers. The topmost customization was the number input mask and user input validation business rules at GUI level
What we did need, was an installation-specific or 3rd-party-system-specific message customization. For this customization you'll need rather the list of vendors of hardware and software your system will talk to. Once you have it, check their hl7 conformance statements
Both are serialization libraries and are developed by Google developers. Is there any big difference between them? Is it a lot of work to convert code using Protocol Buffers to use FlatBuffers?
I wrote a detailed comparison of a few serialization systems, including Protobufs and FlatBuffers, here:
https://kentonv.github.io/capnproto/news/2014-06-17-capnproto-flatbuffers-sbe.html
However, the comparison focuses more on comparing the three new "zero-copy" serialization systems, and includes Protobufs mostly as a reference point. Also, I'm the author of Cap'n Proto, and also the author of Protobufs v2 (I was responsible for open sourcing Protobufs at Google), so the comparison may be biased.
(Updated in 2021:) Note that Protobufs was introduced at Google way back in 2001 or so and remains the "lingua franca" there today. FlatBuffers was introduced in 2014 and is used in some projects, but Protobuf remains Google's main data interchange format, and there is no intention to change that. To be fair, Google probably couldn't change this if they wanted to, there's just too much code.
I am doing Research on the HL7 Version 3 messaging standard. I was told that hl7 version 2 implementations don't really support multimedia data processing (images, videos, etc.). However this blog: http://www.hl7standards.com/blog/2006/10/18/how-do-i-send-a-binary-file-inside-of-an-hl7-message/ states, that the ed (encapsulated data) data type already exists in the version 2 standard. i even found the speciation for the ed data type in chapter 2 of the hl7 v2.3.1 standard. So it is possible to send image data in hl7 v2 messages.
Also, the processing is the same: there can be a reference to the multimedia data (i.e. url) and there can be base64 encoded data.
I am aware of the fact that both sending system and receiving system have to support the ed data type. So there is the possibility that hl7 v2 implementations don’t support this data type. But other than that, is there really a difference?
Thank you!
PS:Of course I’m not talking about the main difference: the model driven methodology of hl7 v3. my scope is only the processing of multimedia data.
I used to work for a large Hospital group in the middleware department where we transfered ORU messages with embedded AND linked (url) PDF's inside of HL7 V2.3.1 or V2.2, can't remember. As for the binary messages, we used the OBX-5 field to store the messages.
So yes, HL7 V2.x should support this.
However, you have to be careful since each country has its "own" implementation of HL7 - even each hospital "misuses" the one or another field for their own purpose.
In HL7 v2.5 OBX-5 length is variable, e.g. you can use a ED datatype to put binary data of size 65536 (64KB), so it can hold small images. But for multimedia messages I recommend to use the DICOM protocol.
In version 2.2 the OBX-5 field is defined as "Observation Results", string data up to a maximum length of 65 bytes. It also says it can be repeated up to two times. That doesn't sound like you could fit much binary data in there.