We've encountered something we haven't seen before. Looking through the HL7 documentation/standards has left me scratching my head.
We are sending in a standard outbound report message (ORU^R01). It contains MSH, PID, OBR, and OBX segments. In all other cases where we've implemented our system, we get back an acknowledgement that looks like this:
MSH|^~\&|PRODUCTNAME|DESTINATION|^P||YYYYMMDDHHMMSS||ACK|MESSAGEID|T|2.5\
MSA|AA|MESSAGEID|ACK
However, there is a new system that is returning this:
MSH|^~\&|PRODUCTNAME|DESTINATION|^P||YYYYMMDDHHMMSS||ORU^R01|MESSAGEID|T|2.5\
MSA|AA|MESSAGEID|ACK
Notice MSH-9 in the ack. It isn't ACK it is the ORU^R01. Now, we use HAPI to process HL7 messages and it doesn't like this response. I can't tell if this conforms to the HL7 spec (2.5).
Any ideas?
To expand on my previous comment, I read the HL7 v2.5 standard a little bit.
According to my understanding the MSH-9 field contains three components defines as follows:
Components: <Message Code (ID)> ^ <Trigger Event (ID)> ^ <Message Structure (ID)>
Each of those has a corresponding table of legal values: HL7 Table 0076 - Message type, HL7 Table 0003 - Event type and HL7 Table 0354 - Message structure.
Looking at these tables, I would say that an ORU message should have an MSH-9 value of ORU^R01^ORU_R01and an acknowledgement should be ACK^R01^ACK.
Therefore the new system seems to be breaking the standard and HAPI is right to reject it, if it tries to validate the message against the standard.
The main point here is, that the receiving application should be able to decide, where to route and what to do with the message only looking at the MSH fields, without going in to following segments. Therefore you cannot put into the acknowledgment message the exact same MSH that the incoming message had, because it would not identify then the header does not match the message structure.
I mainly referenced HL7 Standard version 2.5 Chapter 2 for this answer.
Related
I am working on building a replacement to MIRTH and it looks like we are sending out non-standard HL7 ORU_R01 messages. OBR.5 should be just a single field but looks like we are sending a bunch of other data in this section.
<OBR.5>
<OBR.5.1>XXXX</OBR.5.1>
<OBR.5.2>XXXX</OBR.5.2>
<OBR.5.3>XXXXX</OBR.5.3>
<OBR.5.5>XXXXX</OBR.5.5>
<OBR.5.6>XXXX</OBR.5.6>
<OBR.5.7/>
<OBR.5.8>XXXXXXXXXX</OBR.5.8>
<OBR.5.10>XXXXXXX</OBR.5.10>
<OBR.5.11>X</OBR.5.11>
<OBR.5.12>X</OBR.5.12>
<OBR.5.13>XXXXX</OBR.5.13>
<OBR.5.15>XXXXXXX</OBR.5.15>
</OBR.5>
It seems like I should be able to something like the following.
obr.getObr5_Priority().getExtraComponents().getComponent(2).setData(...)
But I am having issues trying to find the correct way to set the different segments. All the fields are Strings.
Found something that I think has ended up working for us.
ID expirationDate = new ID(obr.getMessage(), 502);
expirationDate.setValue(format2.format(date));
obr.getObr5_Priority().getExtraComponents().getComponent(0).setData(expirationDate);
Where 503 refers to which element you want to set. In this case I am trying to set OBR-5.2. getComponent(0) because it's the first extra component I am adding for this particular segment. I am not sure entirely if my explanation here is correct but it creates a message we need and parses as I'd expect so its my best guess.
Dereived the answer from this old email thread https://sourceforge.net/p/hl7api/mailman/hl7api-devel/thread/0C32A03544668145A925DD2C339F2BED017924D8%40FFX-INF-EX-V1.cgifederal.com/#msg19632481
Using Microsoft Graph, how can I determine which message an outgoing message is a reply to?
The internetMessageHeaders property is not available for items in the Sent Items folder of mailboxes (using the Graph API, at least -- they are available using EWS or IMAP). If it were, I'd look for the in-reply-to header. In the absence of this, is there something in the standard Graph message properties that will tell me this?
You can check the "Subject" or "bodyPreview" to check if the content contains "RE:", if the answer is yes, the message is reply to.
You can group the message by conversationId and then order by lastModifiedDateTime. This way can check if the message is the original one, if it is not ,it will be reply-to/follow-up one.
Get the message list first(/me/messages or /users/{id | userPrincipalName}/messages and so on), and then foreach the message id to call reply api(/users/{id | userPrincipalName}/messages/{id}/reply and so on). The result in the reply is a reply to.
To Test this, you can use the Graph Explorer first and then paste the JSON to a JSON viewer tool. For further use, you need to use net/java and so on to handle.
API reference: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/resources/message
https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/message_reply
I am very new with mqtt design.
As I see from some tutorials in the internet, common mqtt topic has this format: /home/room/device_type/device_id
I could not see the benefit to do that. And have no idea how to use this kind of design.
From my point of view, the device (dev) might subscribe (sub) to control topic and publish (pub) to status topic. Like this:
pub: clients/dev/devid/stat
sub: clients/dev/devid/ctrl
In this way, it seems sub,pub logic is very simple for both clients and devices
Could someone please tell me some good way to design mqtt topic ?
(!) Please do not start topic with '/' (This one has been recommended by HiveMQ Team)
EDIT:
I just figured out that for whatever kind of design, the model must serve-able at least:
Individual control: send control command to a particular device.
Group control: send control command to a group of devices: type, defined group
Able to recieve the status of device.
Thank you very much
I found that the following topic split scheme works very well in multiple applications
protocol_prefix / src_id / dest_id / message_id / extra_properties
protocol_prefix is used to differentiate between different protocols / application that can be used at the same time
src_id is the ID of the mqtt client that publishes the message. It is expected to be the same as "client ID" used to connect to MQTT broker. It allows quick ACL control to check whether the client is allowed to publish specific topic.
dest_id is client ID of the "destination" unit, i.e. to whom the message is intended. Also allows quick ACL control on the broker of whether client is allowed to subscribe to a particular topic. There can be reserved "destination" strings to specify that the message is broadcasted to anyone who is interested. For example all.
message_id is actual ID of the message within used protocol. I usually use numeric value (as string of course), because the IOT or other embedded system that is connected to MQTT broker can have other I/O links and I would like to use the same protocol (but with different transport framing) to control the device using these other I/O links. I usually use numeric message IDs in such communication links.
extra_properties is an optional subtopic which can be used to communicate other MQTT specific extra information (comma separated key=value pairs for example). Good example would be reporting timestamp of the message when it was actually sent by the client. In case of "retained" messages it can help to identify the relevance of the received message. With MQTTv5 protocol that is expected to arrive soon, the need for this subtopic may disappear because there will be other way to communicate extra properties.
Hope it helps.
We have done some work on that for the domain of manufacturing (Industrial-IoT, not IoT!).
In our scenario there are lots of serverside apps of different companies communicating through MQTT. Thus we needed some overall structure. We call this "Manufacturing Message Stack".
The bottom layer is MQTT, then there is the "Messaging Layer". It consists mainly of
basic topic specs
basic payload specs
On top of the messaging layer there are domain message layers covering various domain specific topics as system messages, alerting, physical device / digital twin messages or other manufacturing related messages.
Topics
The topics are roughly defined as <senderapp>/<app-id>/<message-name>/<args> e.g. pacman/pacman-1/gameover (this is a sample for illustration only!)
The developer of an app which publishes MQTT messages defines <message-name> and <args> depending on the semantics of the payload.
The <senderapp> and <app-id> refers to the sending App and allows to quickly select messages from a defines origin (publisher). We deploy Apps in a microservice environment built with Docker, Rancher - and soon - Kubernetes.
Payload
The payload is specified in JSON format. There is a JSON schema reference URL in each
build an URL to an API of the publishing app which holds further information (e.g. JSON schema) of the message sent. Thus a subscriber can get meta data of a MQTT message on demand. Static meta data is not sent with a message to reduce the payload size.
Payload sample:
{
"$schema": "http://app/api/messages/message1.json",
"score": 1234,
"highscore": false
}
Publisher's message meta data
The publishing app holds an index of all messages which can be sent in an API at
http://<app>/api/messages/index.json:
{
"message1": "message1.json",
...
}
Each message is described by its JSON schema message1.json:
{
"$schema": "http://json-schema.org/draft-06/schema#",
"title": "Pacman end of game",
"properties": {
"score": {
"description": "Players score at the end of game",
"type": "integer"
},
...
}
}
Unfortunately we did not publish our manufacturing message stack yet. Publishing is planned in the next months. Feedback is welcome.
I think if topics are to reflect the physical world, we should look at something like Signal K.
EDIT:
That spec is also still maturing, but it includes concepts like "self" for the server/broker, and a tree that can start at the current vessel/home, but easily extends upwards to other vessels/aircraft/things.
My two cents:
All topics are read-only unless they end in "/set"
Ideally, topics are reasonably normalized and granular. I can understand grouping values up into a group topic. IMHO, this kind of decision should be application-specific.
Payloads should be strings, to avoid endian-ness issues
Here's one suggested tree:
broker = information of this specific broker
broker/clients
broker/clients/count
broker/clients/0/name or broker/clients[0]/name
broker/topics
home = this current location (could also be "here" or something)
home/kitchen/temperature "19C"
home/kitchen/temperature/hardware/type "ESP8266"
home/garage/maindoor/set "closed"
locations = list of all known locations
locations/0/uuid
locations/0/name
locations/0/address
Could somebody please explain the logic of Message-ID created by MS Outlook? especially this part “D45A2C0A.EB29”
User-Agent: Microsoft-MacOutlook/14.6.9.160926
Date: Tue, 22 Nov 2016 17:08:26 -0600
Subject: Video playback error
From: “AAAAAAAAAAAA AAAAA, BBBBB (BBBBB AAAAAA)”
<bbbbb.aaaaa#my.domain.com>
To: “ZZZ, YYYY P (YYYY ZZZZ)” <yyyy.zzz#my.domain.com>
Message-ID: <D45A2C0A.EB29%bbbbb.aaaaa#my.domain.com>
Thread-Topic: Video playback error
MIME-Version: 1.0
Content-type: multipart/mixed;
boundary="B_3563051944_9433913"
RFC2392 confirms that 'both message-id and content-id are required to be globally unique. 'My question is specific for MS Outlook. I would like to know, what kind of logic used by MS Outlook to create the unique number? Can I extract time/date from that Hexadecimal number?
According to RFC2822 - Internet Message Format, the Message ID should be unique for each instance of the message. It's considered optional and how the MESSAGE-ID field is created is up to the server:
The "Message-ID:" field provides a unique message identifier that
refers to a particular version of a particular message. The
uniqueness of the message identifier is guaranteed by the host that
generates it (see below). This message identifier is intended to be
machine readable and not necessarily meaningful to humans. A message
identifier pertains to exactly one instantiation of a particular
message; subsequent revisions to the message each receive new message
identifiers.
Note: There are many instances when messages are "changed", but those
changes do not constitute a new instantiation of that message, and
therefore the message would not get a new message identifier. For
example, when messages are introduced into the transport system, they
are often prepended with additional header fields such as trace
fields (described in section 3.6.7) and resent fields (described in
section 3.6.6). The addition of such header fields does not change
the identity of the message and therefore the original "Message-ID:"
field is retained. In all cases, it is the meaning that the sender
of the message wishes to convey (i.e., whether this is the same
message or a different message) that determines whether or not the
"Message-ID:" field changes, not any particular syntactic difference
that appears (or does not appear) in the message.
I just wanted to know When we send a End Visit Notification as Hl7 Message ,Can we include the below segments in the Hl7 Message ( ADT^A03) when we send End Visit Notification ?
AIL - Appointment Information - Location Resource
AL1- Patient Allergy Information
CON - Consent Segment
CTD - Contact Data
DG1 - Diagnosis
DMI - DRG Master File Information
FAC - Facility
IAM - Patient Adverse Reaction Information
LAN -Language Detail
NTE -- Notes and Comments
ODS -- Dietary Orders, Supplements, and Preferences
PD1 -- Patient Additional Demographic
PID - Patient Identification
PR1 -- Procedures
PRA -- Practitioner Detail
PRB -- Problem Details
PRD Provider Data
PV1 Patient Visit
PV2 Patient Visit - Additional Information
RF1 Referral Information
TCD Test Code Detail
And also I just wanted to know, Is there a limit on using the no of segments in a single HL7 Message?
Any help with this really appreciated it?
Thanks
Ramana
As the HL7 messages are open according the specification, you can in theory add as many segments or segment groups after you fulfilled at least the minimal required segments for an ADT^A03 messages as the standard requests.
MSH Message Header
EVN Event Type
PID Patient Identification
PV1 Patient Visit
HL7 says, that you should ignore fields or segments after the defined, if you do not know them . So there is no limit.
But many communication systems or receivers are limited either by physical (receive stack) or other reasons (strict defined message templates). So in practice you have to come to an agreement with your communication partners.
You can download whichever version of the HL7 V2.x messaging standard you are using and check the exact definition of the A03 trigger event in chapter 3, section 3.3.3. It will show you exactly which segment types are allowed in the ADT_A03 message structure.