For questions about this archive, please contact webmaster@hl7.org.
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?
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!
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?
Or @John Rhoads
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?
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:
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.
@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?
@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.
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.
@John Rhoads @Rene Spronk Thank you very much for your detailed response! let me do some further research on the things you suggested.
@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?
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.
@John Rhoads Thanks for your detailed response! This is pretty helpful.
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!
@Matt Szczepankiewicz Sorry for the confusion. The sentence should say, One of the Interventions for addressing the second Goal also addresses the first Goal.
@Lisa Nelson Okay. Thanks!
FHIR Workshop at University of Washington in September: https://www.iths.org/blog/event/university-of-washington-fhir-workshop/
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