Difference between revisions of "OID RID Linking"
Dave.Boerner (talk | contribs) |
Dave.Boerner (talk | contribs) |
||
Line 3: | Line 3: | ||
<br><br> | <br><br> | ||
The first step is to ensure we create an order that will be associated to multiple resultables. The below does not qualify as only one resultable came back for the order. | The first step is to ensure we create an order that will be associated to multiple resultables. The below does not qualify as only one resultable came back for the order. | ||
− | <br><br>[[Image: | + | <br><br>[[Image:oid111.jpg]]<br><br> |
This is a good example of an order that came back with multiple results. | This is a good example of an order that came back with multiple results. | ||
<br><br>[[Image:oid2.jpg]]<br><br> | <br><br>[[Image:oid2.jpg]]<br><br> | ||
Line 11: | Line 11: | ||
<br><br>[[Image:oid4.png]]<br><br> | <br><br>[[Image:oid4.png]]<br><br> | ||
From a connectR standpoint we can see that this message is only sending one resultable for the order. As a result you will only see one result in the Order view. Resultables are tied to the obx segement which is highlighted. | From a connectR standpoint we can see that this message is only sending one resultable for the order. As a result you will only see one result in the Order view. Resultables are tied to the obx segement which is highlighted. | ||
− | <br><br>[[Image: | + | <br><br>[[Image:oid51.png]]<br><br> |
In this example we have a connectR message that has multiple resultables coming back, one for each obx segment (highlighted). | In this example we have a connectR message that has multiple resultables coming back, one for each obx segment (highlighted). | ||
− | <br><br>[[Image: | + | <br><br>[[Image:oid61.png]]<br><br> |
==Summary== | ==Summary== | ||
In order to correctly receive multiple results for one order the following steps must be taken. | In order to correctly receive multiple results for one order the following steps must be taken. | ||
#Link the correct resultables to the orderable dictionary under TWAdmin. | #Link the correct resultables to the orderable dictionary under TWAdmin. | ||
#Ensure that each obx segment is sending it's specific resultable code to associate to the correct order (defined in the obr section). | #Ensure that each obx segment is sending it's specific resultable code to associate to the correct order (defined in the obr section). |
Latest revision as of 15:58, 27 October 2010
Scenario
The client is looking to have all resultables for an order display correctly in an order in the EHR via an unsolicited interface.
The first step is to ensure we create an order that will be associated to multiple resultables. The below does not qualify as only one resultable came back for the order.
This is a good example of an order that came back with multiple results.
This is the view of the orderable dictionary under TWAdmin - Dictionaries - Orderable Item. In this example you'll see that only one resultable is linked to this orderable in the Results section. If you want to test this order for multiple results then you will need to tie new resultables to this orderable in this Results section.
In this view we see an orderable that have multiple resultables associated to the orderable.
From a connectR standpoint we can see that this message is only sending one resultable for the order. As a result you will only see one result in the Order view. Resultables are tied to the obx segement which is highlighted.
In this example we have a connectR message that has multiple resultables coming back, one for each obx segment (highlighted).
Summary
In order to correctly receive multiple results for one order the following steps must be taken.
- Link the correct resultables to the orderable dictionary under TWAdmin.
- Ensure that each obx segment is sending it's specific resultable code to associate to the correct order (defined in the obr section).