Stream: implementers
Topic: Place a V2 message in a FHIR resource
Brian Reinhold (Jul 01 2020 at 21:31):
I would like to use a FHIR resource to upload an HL7 V2 message (PCD-01 in this case). There are numerous possibilities but so far all the options I have looked at seem to bend the intentions a little too much. Perhaps the composition resource really meant for CDAs...? The PCD-01 message is nothing but a human readable string (to the extent one can read V2 messages). There would be several reasons for doing this ...
Vassil Peytchev (Jul 01 2020 at 21:41):
"Upload" can mean many different things, is there a more specific use case?
Brian Reinhold (Jul 01 2020 at 21:58):
Yes. PCD-01 is much more efficient in terms of bandwidth to upload from a remote location (a gateway reading a medical device). It would be nice to use the same infrastructure to upload PCD-01 messages (to be later rendered) one uses to upload FHIR. One could always use the valueString in the Observation - it would work but I don't know how well that would be received.
Richard Townley-O'Neill (Jul 02 2020 at 06:45):
Would DocumentReference do?
Brian Reinhold (Jul 02 2020 at 09:01):
@Richard Townley-O'Neill It looked like a good idea - as did the Binary - but both of them require base64 encoding which makes them bigger by quite a bit. Either would be great if one had the option NOT to use base64 encoding. I suppose one could zip the V2 message and encode that in base64 and one wouldn't lose too much in the way of efficiency.
John Moehrke (Jul 02 2020 at 12:01):
I understand you want to continue to use HL7 v2 on the transport for the compactness... and are just looking for a deterministic way to convert that information into FHIR? If so, then that is typical #v2 to FHIR stream discussion
John Moehrke (Jul 02 2020 at 12:08):
The idea of tunneling HL7 v2 in FHIR is different. And would require some escaping, hence why Binary and Attachment tends to just base64 encode as it is original content agnostic. There are some discussions on if this base64 is really necessary as the String escaping might be sufficient ( you also indicate). Thus there is efforts to evaluate use of String where base64 is used... but that is not useful until that happens.
John Moehrke (Jul 02 2020 at 12:10):
So using Observation valueString seems is where you get your question of "how well that would be received". It is a string, so it is legitimate. However it is not a string from the perspective of typical strings are displayable to a human. Would be nice if we had a valueBlob that was datatype String with simply String escaping, but then one would need to know things like the metadata found in the Attachment datatype (contentType, language, etc)... so this is already valueAttachment except for the above mentioned base64 encoding.
John Moehrke (Jul 02 2020 at 12:11):
so, use valueString or valueAttachment for now, and recognize that your use is "Trial Use" with this known technical-debt.
Brian Reinhold (Jul 02 2020 at 12:34):
@John Moehrke I think you have picked the best option for us. We already use the Observation in PHD uploads. The problem with PCD-01 uploads in PCHA is that the only non-deprecated option is to use web services with SAML authentication. This option is far more complicated and cumbersome than oAuth. The SAML token alone is bigger than most PCD-01 messages. Using the Observation valueString and the right set of codes we could even split the PCD-01 into the device representation part and reference that observation from those uploading only measurement OBXes. Using this approach we reuse existing software for FHIR uploads and its a relatively efficient way to upload a sequence of streamed measurements in one Observation resource instead of 100s using FHIR alone. An OBX segment is far smaller than an Observation resource!
John Moehrke (Jul 02 2020 at 12:44):
There are others in the camp of liking everything about http REST; but not a fan of verbosity of JSON or XML. Some solutions are to just put stream compressing on each end of a long-standing stream (Examplar: http/2). With that solution the ends of the communication are off-the-shelf JSON, while they benefit from transport compression. And given that the transport is what has the bandwidth problem, it is useful to have transport solve the problem.
John Moehrke (Jul 02 2020 at 12:45):
Thus your specification would just be a normal FHIR implementation guide. You would NOT tunnel HL7 v2 inside a FHIR Observation string. Because you have faith in the transport to do the right compression... sometimes it is useful to have faith in foundational standards and not look to re-invent a solution they have already solved.
Vassil Peytchev (Jul 02 2020 at 12:54):
I am not sure what you mean by using "the same infrastructure ... one uses to upload FHIR" - there is no single infrastructure "to upload FHIR".
Since in the case of PCD-01, the core of the message is an observation, creating an Observation resource using the FHIR RESTful create interaction can achieve the same effect as the PCD-01 transaction, provided that the source of the observation can properly reference the Patient, Device and probably Encounter resources as known by the recipient.
If you are thinking about HTTP in general as the infrastructure, then there is HL7 Over HTTP, which describes how to send HL7 version 2 messages over HTTPS.
Kevin Mayfield (Jul 02 2020 at 13:18):
Agree with @Vassil Peytchev answer. I would go for HL7v2 over Http.
Brian Reinhold (Jul 02 2020 at 15:11):
@Vassil Peytchev All I mean is that existing software can be used to do the job. PCHA has a standard for uploading V2 PCD-01 messages but it used SAML authenticated web services. They DID have a standard which was almost identical to v2 over https it just added oAuth. But they deprecated it because of lack of adoption. That is the most efficient solution (without transport compression).
However, using FHIR means one can use all the server applications that already exist and HAPI FHIR and PCHA FHIR upload protocols which are in place and implemented. In other words, the least amount of additional work...
Last updated: Apr 12 2022 at 19:14 UTC
