Is the order of repeated segments in EDI important. For example, if the implementation guide suggests DTP segment with Date/Time Qualifier 401 to be followed by DTP segment with Qualifier 404, is it required for these segments to be in that order? Or is it right to have them in reverse order?
The order shouldn't matter, unless the trading partner is expecting a certain order (They shouldn't, but I have seen it where the trading partner will be looking for the first segment instead of looking for the qualifier.)
The DTP segments can be in any order.
Related
Does anyone know whether it is common to see values in the OBR segment not match the values from similar concepts in the ORC segment for laboratory diagnostic result HL7 ORU messages?
For example:
ORC.7.6 - Priority
OBR.27.6 - Priority
Can it be possible that the ORC shows "routine", but one of the OBR values underneath that shows "stat" for one of a few tests ordered? (So that parsing logic needs to look at OBR first, OCR second to be accurate?)
Similarly, can this same phenomenon happen with the ordering provider?
ORC.12 - Ordering Provider
OBR.16 - Ordering Provider
For example, if a physician orders a Hep B test that comes back as positive, and the lab's middleware has rules that order a reflux test for Surface B antigen or something else automatically, then the original ordering physician isn't who technically placed the reflux order, but the middleware rule. How is this usually expressed between the ORC.12 and OBR.16 segments corresponding to the ordering provider?
(Don't think it's relevant, but we're reading HL7 v2.5.1 ORU messages)
The ORC is Common Order Segment. The OBR is Observation Request Segment.
The data in those respective segments is related to that specific segment. It may or may not be same.
I know that the order of fields and components matter, but what about the order of segments in an HL7 message?
They all obviously have to have the MSH at the beginning, but is there anything in the HL7 guides that explicitly state that hl7 Segments must be in a particular order.
Certainly, the documentation lists segments in a certain order when describing a message type, but isn't that just the order it was written down? Do you need to have your messages in the same order (other than the grouped items)?
I would have thought that the PID-1 would be irrelevant if the order was set by the order in the message.
I'm keen to hear any opinions, but I would particularly like to hear from someone that can reference some documentation that specifies this.
Yes it does matter -
There is a specific requirement that a required segment be in between two identical segments.
From version 2.5.1 chapter 2:
A named segment X may occur more than once in an abstract message
syntax. This differs from repetition described earlier in this
section.
When this occurs, the following rules must be adhered to:
If, within an abstract message syntax, a named segment X appears in two
individual or group locations, and a) Either appearance is optional or
repeating in an individual location; b) or, either appearance is
optional or repeating, in a group location then, the occurrences of
segment X must be separated by at least one required segment of a
different name so that no ambiguity can exist as to the individual or
group location of any occurrence of segment X in a message instance.
A real world example of this is ROL segments in ADT^A02, one follows PD1, and one follows PV2, but PV1 is required in between the two.
If you're writing some kind of parser though, I would be wary of anyone actually respecting this rule.
Absolutely. The order of segments is defined in the HL7 standard.
For example (I'm using version 2.4 International) section 4.4.1 ORM ‑ general order message (event O01) regarding Order Entry shows the following as the structure of an ORM order message (formatting is not ideal)
ORM^O01^ORM_O01
MSH
[{NTE}]
[
PID
[PD1]
[{NTE}]
[
PV1
[PV2]]
[{IN1
[IN2]
[IN3]
}]
[GT1]
[{AL1}]
]
{
ORC
[
<OBR|RQD|RQ1| RXO|ODS|ODT>
[{NTE}]
[CTD]
[{DG1}]
[{
OBX
[{NTE}]
}]
]
[{FT1}]
[{CTI}]
[BLG]
}
The square brackets indicate possible repetitions, and the curly brackets that segments are optional (for example directly after the MSH you could have 0, 1 or n NTE segments.)
To be a valid ORM message, an OBR segment should come after an ORC segment that itself should come after a PID etc. An OBR segment is thus for example not allowed to be sent before a PID segment (see this as a layer structure, the Observation Request comes under an Order Common segment that itself is related to a Patient Visit that is specific to a Patient.)
The PID-1 field you mentioned is not a good example, as most messages will only have one PID segment, and PID-1 thus be 1. (I'm not aware of messages containing more than one PID segment, please add to the comments if anyone knows concrete examples from the HL7 specs). But if you look at for example OBR-1, there can be multiple Observervation Requests in the same Order message, for example an order for a Kalium and a Natrium, there would thus be a sequence number sent in OBR-1 to ensure data from the different orders are not mixed up, e.g.:
ORC|...
OBR|1|12345||KA^Kalium|...
OBR|2|12346||NA^Natrium|...
I am finding that the passages returned by Discovery are generally very good choices... but they are too short and truncated at odd points... even mid sentence. A couple of questions:
Is there a way to control the passage length returned?
Is there a way to bring the user directly to the passage within the full document?
It looks like they Discovery Query API now supports controlling the passage length, although the SDK's (Java and NodeJS) haven't been updated yet to support it.
passages.characters The approximate number of
query characters that any one passage should have.
integer The default is 400. The minimum is 50. The
maximum is 2000. Note: The passages.characters
parameter is supported only on private
collections. It is not supported in the
Watson Discovery News collection.
1) Currently, passage length is fixed at 200 characters, though it will generally not be exactly 200 as passages start and end at word boundaries.
2) No.
This is a problem with Watson Discovery. The answer seems to be if you need longer answers, to divide your documents into short sub-documents and make those part of your collection. For instance, I use discovery with my syllabus to help students who have questions about class and university policies. I divide each sub-section into its own document. Discovery can then produce the entire document (which is not more than a paragraph).
Even though loops are kind of a logical concept in X12 (not directly physically represented in the text), every transaction set defines a set of loops that it can contain, including identifiers for the loops and an ordering for them. My question is, what is the rule for sorting loops, generically? Is there a concise set of rules that can be expressed in some code that should be able to take a collection of loops (with known identifiers such as 1000A, 2300BB, etc) and properly sort them?
The context of my question is that I'm working on a general-purpose library that applications will use to construct a model of an X12 document/transaction-set (and write out the text such a model represents). It has objects to represent Elements, Segments, and Loops. Ordering of Segments in a particular Loop is easy, they're dictated by the Implementation Guides. But I'm trying to get Loop ordering (within a Transaction Set) to work generically; that's what I'm asking about
It seems that the general rule is that Loops are ordered based on their identifiers using the numeric portion as the primary sort key, with the alpha portion as the secondary sort key. Of course hierarchical loops contained in others will be placed before and loops following the parent in that sort order (eg: 1000A, 2000A, 2010A, 2010B, 2100, 2300 - where 2010A and 2010B are children of 2000A).
I understand that the spec and Implementation Guides contain all of this info; I'm looking for the all-encompassing rule about loop ordering (not Segment ordering). Is there any concise way to express the rule algorithmically? Is there even a hard-and-fast rule at all?
As I mentioned in my comments, the standard has a loop value. Take a look at my screenshot of the Liaison Dictionary Viewer. The CLM segment has a LOOP value of 100. The segments underneath are children of the CLM segment (extended tag). Any "order" can be defined arbitrarily by the partner, or can be in any (undefined) order provided the data is qualified. But that loop can occur 100 times max and can have repeating segments inside the loop value.
The implementation guide will give you the correct order your partner wants them in. It seems like you're writing your own syntax validation engine though.
I've seen XML before, but I've never seen anything like EDI.
How do I read this file and get the data that I need? I see things like ~, REF, N1, N2, N4 but have no idea what any of this stuff means.
I am looking for Examples and Documentations.
Where can I find them?
Aslo
EDI guide i found says that it is based on " ANSI ASC X12/ ver. 4010".
Should I search form X12 ?
Kindly help.
Several of these other answers are very good. I'll try to fill in some things they haven't mentioned.
EDI is a set of standards, the most common of which are:
ANSI X12 (popular in the states)
EDIFACT (popular in Europe)
Sounds like you're looking at X12 version 4010. That's the most widely used (in my experience, anyway) version. There are lots and lots of different versions.
The file, or properly "interchange," is made up of Segments and Elements (and sometimes subelements). Each segment begins with a two- or three-word identifier (ISA, GS, ST, N1, REF).
The structure for all documents begins and ends with an envelope. The envelope is usually made up of the ISA segment and the GS segments. There can be more than one GS segment per file, but there should only be one ISA segment per file (note the should, not everyone plays by the rules).
The ISA is a special segment. Whereas all the other segments are delimited, and therefore can be of varying lenghts, the ISA segment is of fixed width. This is because it tells you how to read the rest of the file.
Start with the last three characters of the ISA segment. Those will tell you the element delimiter, the sub-element delimiter, and the segment delimiter. Here's an example ISA line.
ISA:00: :00: :01:1515151515 :01:5151515151 :041201:1217:U:00403:000032123:0:P:*~
In this case, the ":" is the element delimiter, "*" is a subelement delimiter, and "~" the segment delimiter. It's much easier if you're just trying to look at a file to put linebreaks after each segment delimiter (~).
The ISA also tells you who the document is from and to, what the version is (00403, which is also known as 4030), and the interchange control number (0000321233). The other stuff is probably not important to you at this stage.
This document is from sender "01:1515151515" and to receiver "01:5151515151". So what's with the "01:"? Well, this introduces an important concept in EDI, the qualifier. Several elements have qualifiers, which tell you what type of data the next element is. In this case, the 01 is supposed to be a Dunn and Bradstreet number. Other qualifiers for the ISA05 and ISA07 elements are 12 for phone number, and ZZ for "user defined". You'll find the concept of qualifiers all over EDI segments. A decent rule of thumb is that if it's two characters, it's a qualifier. In order to know what all the qualifiers mean, you'll need a standards guide (either in hard copy from the EDI standards body, or in some software).
The next line is the GS. This is a functional group (a way to group like documents together within an interchange.) For instance, you can have several purchase orders, and several functional acknowledgements within an ISA. These should be placed in separate functional groups (GS segments). You can figure out what type of documents are in a GS segment by looking at the first GS01 element.
GS:PO:9988776655:1122334455:20041201:1217:128:X:004030
Besides the document type, you can see the from (9988776655) and to (1122334455) again. This time they're using different identifiers, which is legal, because you may be receiving an interchange on behalf of someone else (if you're an intermediary, for instance). You can also see the version number again, this time with the trailing "0" (0004030). Use significant digits logic to strip off the leading zeros. Why is there an extra zero here and not in the ISA? I don't know. Lastly this GS segment also has it's own identifier, 128.
That's it for the beginning of the envelope. After that there will be a loop of documents beginning with ST. In this case they'd all be POs, which have a code (850), so the line would start with ST:850:blablabla
The envelope stuff ends with a GE segment which references the GS identifier (128) so you know which segment is being closed. Then comes an IEA which similarly closes out the ISA.
GE:1:128~
IEA:1:000032123~
That's an overview of the structure and how to read it. To understand it you'll need a reference book or software so you understand the codes, lots and lots of time, and lots and lots of practice. Good luck, and post again if you have more specific questions.
Wow, flashbacks. It's been over sixteen years ...
In principle, each line is a "segment", and the identifiers are the beginning of the line is a segment identifier. Each segment contains "elements" which are essentially positional fields. They are delimited by "element delimiters".
Different segments mean different things, and can indicate looping constructs, repeats, etc.
You need to get a current version of the standard for the basic parsing, and then you need the data dictionary to describe the content of the document you are dealing with, and then you might need an industry profile, implementation guide, or similar to deal with the conventions for the particular document type in your environment.
Examples? Not current, but I'm sure you could find a whole bunch using your search engine of choice. Once you get the basic segment/element parsing done, you're dealing with your application level data, and I don't know how much a general example will help you there.
EDI is a file format for structured text files, used by lots of larger organisations and companies for standard database exchange. It tends to be much shorter than XML which used to be great when data packets had to be small. Many organisations still use it, since many mainframe systems use EDI instead of XML.
With EDI messages, you're dealing with text messages that match a specific format. This would be similar to an XML schema, but EDI doesn't really have a standardized schema language. EDI messages themselves aren't really human-readable while most specifications aren't really machine-readable. This is basically the advantage of XML, where both the XML and it's schema can be read by humans and machines.
Chances are that when you're doing electronic banking through some client-side software (not browser-based) then you might already have several EDI files on your system. Banks still prefer EDI over XML to send over transaction data, although many also use their own custom text-based formats.
To understand EDI, you'll have to understand the data first, plus the EDI standard that you want to follow.
Assuming the data stream starts with “ISA”, towards the beginning there should be a section “~ST*” followed by three numeric digits. If you can post these three digits, I can probably provide you with more information. Also, knowing the industry would be helpful. For example, healthcare uses 270, 271, 276, 277 and a few others.