Chat.HL7.org Zulip Archive

For questions about this archive, please contact webmaster@hl7.org.

Stream: general

Topic: HL7


view this post on Zulip arunraghuram (Jul 11 2018 at 23:09):

Not sure if this is the right place to ask : I am looking for a method to identify devices using HL7 traffic. Is there a way given HL7 messages by which I can identify the vendor and type of devices I have in my network (e.g. Medlink - Xray, Alaris - IV pump). Are there specific messages I should be looking at to achieve this? Are the PRT segment and OBX-18 the relevant sources of information?

view this post on Zulip David Johnson (Jul 12 2018 at 13:21):

This is an interesting question. I don't have the answer but I will see what I can do to help you find it. Thanks for using chat.hl7.org!

view this post on Zulip Anne Wizauer (Jul 12 2018 at 13:31):

I know @John J Garguilo is part of the Health Care Devices work group...he may be able to help or point in the right direction?

view this post on Zulip Anne Wizauer (Jul 12 2018 at 13:39):

Or @John Rhoads

view this post on Zulip arunraghuram (Jul 12 2018 at 16:38):

Thanks @David Johnson , look forward to your response . @Anne Wizauer are @John J Garguilo / @John Rhoads active on here? or would you know the best way to reach them?

view this post on Zulip David Johnson (Jul 12 2018 at 17:45):

It's highly likely that tagging them in your question auto-sends an email that will send them here. Let's give them the opportunity to respond. :calling:

view this post on Zulip Rene Spronk (Jul 13 2018 at 07:10):

If the HL7v2 messages are implemented according to the IHE PCD profile it'll relatively easy to identify the device. However, most devices don't communicate using HL7 v2, they use converters to transform their own data structures into HL7v2 (PCD describes this as well). Such conversions are mostly focused on the measurements themselves, not on the device which did the measuring. As such most messages probably won't identify the device at all - it can only be inferred from the type of measurements done.

view this post on Zulip arunraghuram (Jul 13 2018 at 18:57):

@Rene Spronk , thanks for your informative response, I will definitely dig into this deeper. A couple of follow up questions, any help is appreciated: (a)If HL7v2 messages are implemented according to the IHE PCD profile on the device what level of granularity we can get on the device type by observing traffic? - e.g. can we specifically know it is an Alaris IV pump model 8100 or just that its an Alaris pump? or just know that its an IV pump and nothing else? and b) If the devices don't communicate with HL7v2 directly and utilize a converter, what level of granularity of device type can we hope to infer by the measurements alone?

view this post on Zulip John Rhoads (Jul 13 2018 at 22:57):

@Rene Spronk is certainly correct that devices do not typically communicate via HL7 directly (I know of only a few that do), but rather by a specialized protocol, either one of a few standards (as for example one of the IEEE 11073 Medical Device Communications protocol suites), or more commonly by a one-off proprietary protocol. In order to be of any use in a medical setting, this device protocol needs to be converted for interoperability, usually to HL7 V2. This is most often done by a "gateway" system, either available from the device vendor, an EMR vendor or from a third party (there are a number of companies specializing in this).
The converted data stream may still not include the exact identifying information you are looking for. If the gateway is putting out HL7 V2 data in the IHE Patient Care Device profile (see details on the IHE PCD Technical Framework documents freely available on ihe.net), you should be able to find out what general kind of a device it is (in your example, say, a large-volume infusion pump) and information about its logical structure (channels and so on) and what data it is making available. You also should get a unique identifier for the individual device which can be correlated with an equipment database, if the institution has one, to get the manufacturer and model, but a "user-friendly" form of the manufacturer and model is not currently required to be present in the HL7 stream (this is changing but there will be a time lag in manufacturers implementing it). Feel free to ask specific questions in the IHE PCD technical committee email reflector ihepcdtech@googlegroups.com. Many device manufacturers and gateway system vendors are there.
You can often deduce a lot about the device just from what data it sends, but that it highly specific to the situation.

view this post on Zulip Rene Spronk (Jul 14 2018 at 06:20):

Definitely. If you already know up front what devices exist in a given organisation, just looking at the data may be sufficient to deduce what piece of equipment generated it. But if you don't have a clue as to what equipment they have such a deduction process will be near to impossible unless the message actually carries the detailed information. In an HL7 context most EHRs don't really care what type/instance of equipement produced an item of data (a lab system might care, but a more general EHR doesn't), which is why this is omitted in most Hl7 v2 communications. IHE PCD (and IEEE 11073) is your best bet.

view this post on Zulip arunraghuram (Jul 16 2018 at 23:59):

@John Rhoads @Rene Spronk Thank you very much for your detailed response! let me do some further research on the things you suggested.

view this post on Zulip arunraghuram (Jul 23 2018 at 22:30):

@John Rhoads @Rene Spronk , a couple of questions (a)John, In your response, you mention that I should be able to get a unique identifier for the individual device which can be correlated with an equipment database. Are you referring to a MAC address or UDI number which is present in the HL7 traffic? Would you happen to know what segments carry these identifiers? So far I have found the PRT segment and OBX-5 to be relevant. (b) I see that IHE PCD-15 (MEMDMC) seems to have the identifier, but the IHE product registry says that only 1 vendor has implemented this. Is this accurate?

view this post on Zulip John Rhoads (Jul 24 2018 at 01:39):

In addition to MEMDRC, which is not widely implemented yet, other IHE PCD profiles that contain observations in OBX segments such as DEC (Device Enterprise Communications), with the most widely implemented transaction, PCD-01, prescribe putting a unique device identifier in the message reporting observations. Most now put it in OBX-18 of a particular OBX segment (for details see vol.2 of the IHE PCD Technical Framework. The IEEE EUI-64, which has the (more or less) format of a IPV6 MAC address, is currently the preferred form, but in future implementations a PRT segment carrying an FDA Unique Device Identifier (UDI) is likely to supplant this.

view this post on Zulip arunraghuram (Jul 24 2018 at 21:12):

@John Rhoads Thanks for your detailed response! This is pretty helpful.

view this post on Zulip Matt Szczepankiewicz (Aug 07 2018 at 16:38):

Apologies if this isn't the best place to ask this, but:

I'm looking at Care Plan scenario #1B for the C-CDA implementation-a-thon this week, which mentions: "Create a Care Plan Document that has 1 Health Concern." It then goes on to say "One of the Goals for addressing the second Health Concern also addresses the first Health Concern." So I'm confused about what this is supposed to be--how many Health Concerns should the Care Plan in this scenario have?

Thanks for any help!

view this post on Zulip Lisa Nelson (Aug 08 2018 at 21:40):

@Matt Szczepankiewicz Sorry for the confusion. The sentence should say, One of the Interventions for addressing the second Goal also addresses the first Goal.

view this post on Zulip Matt Szczepankiewicz (Aug 09 2018 at 01:57):

@Lisa Nelson Okay. Thanks!

view this post on Zulip David Johnson (Aug 17 2018 at 12:18):

FHIR Workshop at University of Washington in September: https://www.iths.org/blog/event/university-of-washington-fhir-workshop/

view this post on Zulip Patricia Guerra (Aug 20 2018 at 13:41):

thanks, letting Mark know as he may wish to contact them about proper attribution of FHIR. I noticed that Stan Huff is involved.


Last updated: Mar 23 2020 at 00:02 UTC