Standards Australia
Information in fields should be filled in if known or left as is.
Australian diagnostic—Pathology and Radiology—
Reporting profile
Part Title:
Click here and type Part Title
Designation:
Click here and enter designation (e.g.AS/NZS 1234:1998)
Part Number:
Click here and type Part Number (do not include the word PART)
Supersedes Standard No: Click here and type Superseded Standard Number
AustralianORJoint:
Australian
Creation Date:
2009-04-24
Revision Date:
2009-06-26
Issue Date:
July 2009
Committee Number:
IT-014
Committee Title:
Health Informatics
Subcommittee Number: IT-014-06-05
Subcommittee Title:
Diagnostic Messaging
Project Manager:
Julie Lam
PMs Email Address:
julie.lam@standards.org.au
WP Operator:
Mercer/Tokelau
Project Number:
9011
Combined Procedure?: No
Committee Doc No.:
ONE Alpha followed by FOUR numerical (eg: N9999)
Stage:
PRELIMINARY
Committee Reps:
Click here and type committee reps using shift return for new line
Additional Interests:
Click here and type organisation names using shift return for new line
Product Type
AS
Document Status
Current
Document Availability
Private
106747852 - 06/03/2016 7:21:12
DRAFT ONLY
2
PREFACE
106747852 - 06/03/2016 7:21:12
DRAFT ONLY
DRAFT ONLY
3
DRAFT ONLY
CONTENTS
1
Page
INTRODUCTION ....................................................................................................... 4
2
ELECTRONIC DIAGNOSTIC REPORTING ............................................................ 5
3
ACTORS/ROLES ....................................................................................................... 5
4
RECEIPT OF DIAGNOSTIC REPORT MANAGEMENT ......................................... 6
106747852 - 06/03/2016 7:21:12
DRAFT ONLY
4
DRAFT ONLY
STANDARDS AUSTRALIA
Australian Standard
Australian diagnostic—Pathology and Radiology—Reporting profile
1 INTRODUCTION
Internationally healthcare systems users (and their representative bodies) and vendors (who
often do not have any industry sector representative groups or associations) have formed a
collaboration to tackle the issues of inter-system interoperability.
This approach is known as Integrating the Healthcare Enterprise (IHE) and as a
methodology is being widely adopted internationally completed ISO Ballot
(ISO/CD TR 28380-1 Health
Informatics—IHE
Global
Standards
Adoption—
Part 1: Process Health Informatics). Apart from marketing, there are other major benefits to
vendors from participating in the process:
(a)
Opportunity to meet and work with engineers from collaborating companies away
from the stress of real world implementations:
(b)
Efficient to focus resources over short period;
(c)
Ability to incrementally improve communication;
(d)
Having a clear roadmap and being able to reuse components;
(e)
Creates a level playing field—All have a voice whether large or small, local or
international;
(f)
Provides a forum for getting input from users away from a commercial environment.
IHE first tackled radiology with integration of RIS, PACS and modality systems. It has
since been applied to many other application areas and extended to provide further
functionality.
Further information is available at; www.ihe.net and www.ihe.net.au
1.2 Application to Australian health messaging
For several years organisations such as HL7 and MSIA have been working with application
vendors and communication services vendors to correct a number of well recognised
systemic problems. These include:
(a)
Use of inappropriate message type;
(b)
Variability in HL7 v2.x message designs;
(c)
Variability in the use of acknowledgement messages by both sender and receivers;
and
(d)
A lack of focus on receiver capacity and responsibilities in the messaging chain;
With the introduction of IHE to radiology systems in Australia in 2008 (focusing firstly on
standardisation of images on CDs) there is also the opportunity to apply IHE processes to
the implementation of Australian standard messaging. The reasons for this are:
(i)
Variation is only slowly disappearing from common use due to legacy systems, and
business drivers to rapidly capitalise on new market opportunities;
(ii)
While testing is possible with AHML, this is only part of the testing solution and
AHML can be seamlessly integrated within the IHE testing framework:
106747852 - 06/03/2016 7:21:12
DRAFT ONLY
5
DRAFT ONLY
(iii) The Australian Standards and Implementation Guides (Handbooks) may not fully
cover all ambiguity, and a process to test systems ‘end to end’ is needed;
(iv)
Australian vendors do not currently report on HL7 conformance; and
(v)
Users and purchasers have difficulty in adequately specifying testable and necessary
HL7 standards pre-conditions prior to purchase;
Progress with standard communications, whether by integration of current communication
vendor technologies or a move to adopt Web-Services, is being slowed by the lack of a
standard payload.
As terminology and data model standards are implemented, this will require a rigorous
framework for implementation and testing, and to have other communication components
standardised.
This document provides an Australian IHE profile for the integrated implementation and
testing of HL7 messages, focusing on the AS 4700.2 and AS 4700.7 for diagnostic
(laboratory and radiology) messaging.
2 ELECTRONIC DIAGNOSTIC REPORTING
The Australian specific IHE profile for diagnostic reporting has been developed to
encompass the requirements for diagnostic reporting in Australia, the requirements have
been based on:
(a)
(b)
Pathology:
(i)
AS 4700.2—2004, Implementation of Health Level Seven (HL7) Version 2.4—
Pathology and medical imaging (diagnostics).
(ii)
HB 262—2008, Guidelines for pathology messaging between pathology
providers and health service providers.
Radiology:
(i)
AS 4700.7—2005, Implementation of Health Level Seven (HL7) Version 2.3.—
Diagnostic imaging orders and results
To view list of all available standards and download these documents visit:
http://www.e-health.standards.org.au/drafts.asp?area=publications
NOTE: Where radiology messaging differs this will be noted in a boxed comment.
3 ACTORS/ROLES
3.1 Integrated report creator/deliverer
3.1.1 Report creator
The Report Creator (filler) actor is an application generating an electronic report
(ORU^R01^ORU_R01) for a set of observations and processing an Application
Acknowledgement (ACK^R01).
3.1.2 Report Deliverer
The Report Deliverer actor is an application which transports the electronic report message
(ORU^R01^ORU_R01) and handles acknowledgement processing.
For Original Acknowledgement Mode an Application Acknowledgement (ACK^R01) will
be passed onto the Report Creator.
For Enhanced Acknowledgement mode the report deliverer will additionally process an
Accept Acknowledgement (ACK).
106747852 - 06/03/2016 7:21:12
DRAFT ONLY
6
DRAFT ONLY
3.2 Integrated report receiver/processor
3.2.1 Report receiver
The Report Receiver actor is an application which receives an electronic report message
(ORU^R01^ORU_R01) and handles acknowledgement processing.
For Original Acknowledgement Mode an Application Acknowledgement (ACK^R01) will
be generated by the Report Processor and passed onto the Report Deliverer for transport to
the Report Creator.
For Enhanced Acknowledgement Mode the Report Receiver will additionally generate an
Accept Acknowledgement (ACK).
3.2.2 Report processor
The Report Processor actor is an application which processes and displays an electronic
report (ORU^R01^ORU_R01) for a set of observations and generates an Application
Acknowledgement (ACK^R01).
4 RECEIPT OF DIAGNOSTIC REPORT MANAGEMENT
4.1 Interaction diagram
FIGURE 1 INTERACTION DIAGRAM
4.2 Acknowledgement processing
There are two levels of acknowledgement processing; original and enhanced. Original mode
is an application acknowledgment [ACK^R01]. Enhanced mode includes an additional
accept acknowledgement [ACK]. For this profile HL7 acknowledgement processing is
required and enhanced acknowledgement mode is recommended, though original mode
acknowledgement message details see Clause 4.7.1.2 and 4.7.4.3.
106747852 - 06/03/2016 7:21:12
DRAFT ONLY
7
DRAFT ONLY
4.3 Display format
4.3.1 Report creator
The Report Creator will create reports containing atomic results (see Clause 4.8.1.1 for
required fields), as well as any display segment format they are able to produce. For this
profile, only atomic results will be required and any display segment formats produced by
the Report Creator will be noted as extra functionality.
4.3.2 Report processor
The Report Processor will process reports containing atomic results (see Clause 4.8.4.2 for
required fields), as well as any display segment supported. For this profile, only the display
of atomic results will be required and any display segment formats supported by the Report
Processor will be noted as extra functionality. Where a display segment format is provided
and supported, it will be displayed by the Report Processor in place of rendering the atomic
results.
4.3.3 Display Formats
The following display formats are described in AS 4700.2, Implementation of Health Level
Seven (HL7) Version 2.4—Pathology and medical imaging (diagnostics), and will be an
optional part of this profile.
OBX||FT|HTML^Display format in HTML^AUSPDI||…
OBX||FT|XML^Display format in XML^AUSPDI||…
OBX||FT|PIT^Display format in PIT^AUSPDI||… —(Pathology Only)
OBX||FT|TXT^Display format in text^AUSPDI||…
OBX||ED|RTF^Display format in RTF^AUSPDI||…
OBX||ED|PDF^Display format in PDF^AUSPDI||…
OBX||ED|JPG^Display format in JPG^AUSPDI||…
4.4 Terminology
The Australian Standards (AS 4700.2 and AS 4700.7) call for the use of the following
terminologies:
(a)
AUSPATH for Order Codes (see www.ahml.com.au/austpath.php); and
(b)
LOINC for results:
These will be regarded as optional for production systems, given the lack of agreement and
usage by industry and lack of clear guidance from Australia’s terminology service.
However for the purposes of testing of this profile these terminologies will be used and
must be supported. Other terminologies such as SNOMED-CT may be used optionally by
bilateral agreement between Report Creator and Report Processor.
NOTE: Order and Result codes will be provided for pre-testing.
4.5 Display responsibilities
4.5.1 Comments
Result/Report comments refer to situations where comments are included as part of the
result.
In atomic HL7 format the comments become detached from the overall context of the report
when they are received as separate OBX segments.
The following is a mechanism to align comments with a specific result line or to indicate
that it is a report-wide comment.
(a)
LOINC codes 8251-1 to 8270-1 are used to flag Report comments.
106747852 - 06/03/2016 7:21:12
DRAFT ONLY
(b)
8
DRAFT ONLY
LOINC codes 15412-0 to 15431-0 are used to flag Result comments.
For the above LOINC codes the report processor will not show the code or code name just
the comment text, there may also be an optional heading before the comments stating that
this is a report comment.
4.5.2 Clinical Notes
Clinical Notes (OBR-13) should always be displayed if present in the report. This applies
whether a display segment or atomic data is being rendered.
4.6 Receiving and Copy To Doctor Addressing
4.6.1 Receiving Doctor
The receiving doctor may be sent in three different places, the Report Processor will need to
look in all three places.
(a)
MSH-5—Receiving Application.
(b)
PV1-9—Consulting Doctor.
(c)
OBR-20—Filler Field 1.
4.6.2 Copy to doctors
Copy To Doctors may be sent in OBR-28 if populated they should be displayed by the
Report Processor.
4.7 Messaging
HL7 Messages need to be created based on the following requirements, all messages created
need to be validated through AHML (www.ahml.com.au) against the AS 4700.2 or
AS 4700.7 testing profiles. Content for the messages will be provided and the messages
submitted checked against the provided data.
4.7.1 HL7 Messages
4.7.1.1 ORU^R01—Observational Report (unsolicited)
An ORU^R01 message is the Observational Report message used to report a result.
FIGURE 2 ORU^R01 MESSAGE STRUCTURE
4.7.1.2 ACK—Accept acknowledgement
An accept acknowledgement message means that the receiving application (report receiver
(transport)) has received the message and committed it to safe storage.
106747852 - 06/03/2016 7:21:12
DRAFT ONLY
9
DRAFT ONLY
FIGURE 3 ACK MESSAGE STRUCTURE
4.7.1.3 ACK^R01—Application acknowledgement
An application acknowledgement message means that the receiving application (Report
Processor) has received and processed the message and accepted responsibility for the
message.
FIGURE 4 ACK^R01 MESSAGE STRUCTURE
4.7.2 Message segments
The following outlines the required fields to be supported for this profile, for more detail
see AS 4700.2, AS 4700.7 and HB 262.
NOTE: Optionalilty listed is for this IHE profile. The AS 4700.2 and AS 4700.7, Optionality is
shown in brackets if different. Constraining optionality is done in the interests of ensuring
interoperability.
106747852 - 06/03/2016 7:21:12
DRAFT ONLY
10
DRAFT ONLY
4.7.2.1 MSH
TABLE 1
MESSAGE HEADER (MSH) SEGMENT
SEQ
LEN
DT
OPT
RP#
TBL#
NAME
VALUE/EXAMPLE/NOTES
1
1
ST
R
Field Separator
|
2
4
ST
R
Encoding Characters
^~&\
3
180
HD
R(O)
Sending Application
Name of report creator software
(QMLPTX-v1.6.7)
4
180
HD
R(O)
Sending Facility
Laboratory NATA Number
(QML^2184^AUSNATA)
5
180
HD
O
Receiving Application
This field can be used to identify the
doctor to whom the results are addressed
(AUSHICPR.045678AB^045678AB.HA
NDY.JOHN…Dr^L)
7
26
TS
R(O)
Date/Time of Message
Date/Time message created
(200805211204+1000)
9
7
CM
R
10
20
ST
R
11
3
PT
R
12
60
VID
15
2
ID
16
2
ID
0076
Message Type
ORU^R01^ORU_R01
0003
ACK
0354
ACK^R01
Message Control ID
Unique number assigned by creator
(89dg89s6x6d4564)
0103
Processing ID
P
R
0104
Version ID
2.3.1^AUS&Australia&ISO3166-1
C(O)
0155
Accept Acknowledgement
Type
Original Mode – NE
Application
AL
C(O)
0155
Enhanced Mode – AL
Acknowledgement Type
4.7.2.2 PID
TABLE 2
PATIENT IDENTIFICATION (PID) SEGMENT
SEQ
3
LEN
250
DT
CX
OPT
R
RP#
Y
TBL#
0363
NAME
VALUE/EXAMPLE/NOTES
Patient Identifier List
(4009887514^^^AUSHIC^MC)
Patient Name
(SMITH^BILL^M)
Date/Time of Birth
(19700221)
Sex
(M)
Patient Address
(12 Ash St^^Ballarat^VIC^3000^AUS)
0203
5
250
XPN
R
7
26
TS
C
8
1
IS
O
11
250
XAD
O
Y
0001
Y
106747852 - 06/03/2016 7:21:12
DRAFT ONLY
11
DRAFT ONLY
4.7.2.3 PV1
TABLE 3
PATIENT VISIT (PV1) SEGMENT
SEQ
LEN
DT
OPT
2
1
IS
R
8
250
XCN
O
9
250
XCN
O
RP#
TBL#
0004
NAME
VALUE/EXAMPLE/NOTES
Patient Class
(O)
Y
Referring Doctor
(1029382V^BROWN^BRUCE^^^DR^^
^AUSHICPR)
Y
Consulting Doctor
(1029382V^BROWN^BRUCE^^^DR^^
^AUSHICPR) One option for receiving
doctor
4.7.2.4 ORC
TABLE 4
ORDER CONTROL (ORC) SEGMENT
SEQ
LEN
DT
OPT
1
2
ID
R
3
22
EI
R(C)
5
2
ID
R(O)
RP#
TBL#
0019
0038
NAME
VALUE/EXAMPLE/NOTES
Order Control
(RE)
Filler Order Number
Same as OBR-3 (009384756^QML^2184^AUSNATA)
Order Status
(CM)
4.7.2.5 OBR
TABLE 5
OBSERVATION REQUEST (OBR) SEGMENT
SEQ
LEN
DT
OPT
RP#
TBL#
NAME
VALUE/EXAMPLE/NOTES
1
4
SI
C
Set ID
If more than one OBR (1)
3
250
EI
R(C)
Filler Order Number
Same as ORC-3 (009384756^QML^2184^AUSNATA)
4
250
CE
R
Universal Service ID
AUSPATH Codes to be used in first
triplet (BGAS^Blood
Gases^AUSPRQ^BG^Blood
Gases^NATA2184)
13
300
ST
R(O)
Relevant Clinical Info
(Short of breath - Asthma)
20
60
ST
O
Filler Field 1
(DR=617281A,CP=Y)
25
1
ID
R(C)
Result Status
(F)
28
250
XCN
R(O)
Result Copies To
(617281A^GREEN^GARY^^^DR^^^AU
SHICPR~1029382V^BROWN^BRUCE^
^^DR^^^AUSHICPR )
Y
0123
Y/5
106747852 - 06/03/2016 7:21:12
DRAFT ONLY
12
DRAFT ONLY
4.7.2.6 OBX
TABLE 6
OBSERVATION RESULTS (OBX) SEGMENT
SEQ
LEN
DT
OPT
2
3
ID
R(C)
3
250
CE
R
5
65536
*
R(C)
6
250
CE
7
60
8
RP#
TBL#
0125
NAME
VALUE/EXAMPLE/NOTES
Value Type
Data Type of the observation value in
OBX-5 (FT/CE/NM)
Observation Identifier
LOINC codes to be used in the first
triplet (21600^CREATINE^LN^Cr^CREATINE^NA
TA1234-007)
Observation Value
Observation result value (181)
C(O)
Units
(Mmol/L^millimole/liter^ISO+)
ST
C(O)
Reference Range
For numeric results (35-53)
5
ID
C(O)
0078
Abnormal Flags
(+++)
11
1
ID
R
0085
Observation Result Status
(F)
14
26
TS
C(O)
Date/Time of Observation
(200805211332+1000) Time zone
recommended. Not required for the
display segment.
Y
Y/5
4.7.2.7 MSA
TABLE 7
MESSAGE ACKNOWLEDGEMENT (MSA) SEGMENT
SEQ
LEN
DT
OPT
1
2
ID
R
2
20
ST
R
RP#
TBL#
0008
NAME
VALUE/EXAMPLE/NOTES
Acknowledgement Code
(AA)
Message Control ID
Unique ID of the message this is
acknowledging (89dg89s6x6d4564)
4.7.2.8 ERR
TABLE 8
ERROR (ERR) SEGMENT
SEQ
1
LEN
80
DT
CM
OPT
R
RP#
Y
TBL#
NAME
Error Code and Location
106747852 - 06/03/2016 7:21:12
VALUE/EXAMPLE/NOTES
(PID^1^8^103&Table Value not
found&HL70357)
DRAFT ONLY
13
DRAFT ONLY
4.8 Actor responsibilities
4.8.1 Report creator
4.8.1.1 Create report message (ORU^R01^ORU_R01)
TABLE 9
TABLE OF EVALUATION OF VALUES FOR REQUIRED FIELDS
Atomic Data Fields
Value (If set value)
Verified
MSH
MSH-1
Field Separator
|
MSH-2
Encoding Characters
^~&\
MSH-3
Sending Application
MSH-4
Sending Facility
MSH-7
Date/Time of Message
MSH-9
Message Type
MSH-10
Message Control ID
MSH-11
Processing ID
P
Version ID
2.3.1^AUS&Australia&ISO31661
Accept Acknowledgement Type
AL(for Enhanced Mode)/NE (for
Original Mode)
Application Acknowledgement Type
AL
ORU^R01^ORU_R01
MSH-12
MSH-15
MSH-16
PID
PID-3
Patient Identifier List
PID-5
Patient Name
PID-7
Date/Time of Birth
PID-8
Sex
PID-11
Patient Address
PV1—May be omitted
PV1-2
Patient Class
PV1-8
Referring Doctor
ORC
ORC-1
Order Control
ORC-3
Filler Order Number
ORC-5
Order Status
OBR
OBR-1
Set ID
OBR-3
Filler Order Number
OBR-4
Universal Service ID
OBR-13
Relevant Clinical Info
OBR-25
Result Status
OBR-28
Result Copies To
(continued)
106747852 - 06/03/2016 7:21:12
DRAFT ONLY
14
DRAFT ONLY
TABLE 9 (continued)
Atomic Data Fields
Value (If set value)
OBX
OBX-2
Value Type
OBX-3
Observation Identifier
OBX-5
Observation Value
OBX-6
Units
OBX-7
Reference Range
OBX-8
Abnormal Flags
OBX-11
Observation Result Status
OBX-14
Date/Time of Observation
TABLE 10
TABLE OF EVALUATION OF SUPPORTED
DISPLAY SEGMENT TYPES
Display Formats—Validate any formats supported
HTML
XML
PIT
TXT
RTF
PDF
JPG
4.8.1.2 Receipt of application acknowledgement (ACK^R01)
TABLE 11
TABLE OF RECEIPT EVALUATION
REQUIREMENTS
Receipt of Application Acknowledgement ACK^R01
Decrypt
Log of positive ACK^R01
Date/Time
Message ID
MSA-1 Value
Process for dealing with non-ACK/Timeout
Valid processes:
Re-transmit
Alert Management
Log Review
106747852 - 06/03/2016 7:21:12
Verified
DRAFT ONLY
15
4.8.2 Report deliverer (transport)
4.8.2.1 Deliver messages (ORU^R01^ORU_R01 and ACK^R01)
TABLE 12
TABLE OF DELIVERY EVALUATION
REQUIREMENTS
Deliver Messages
ORU^R01 (To Report Receiver—Transport)
ACK^R01 (To Report Creator)
With Fidelity
To Correct Address
Encryption
Security
Traceability
4.8.2.2 Receipt of accept acknowledgement (ACK)
TABLE 13
TABLE OF RECEIPT EVALUATION
REQUIREMENTS
Receipt of Accept Acknowledgement (ACK)
Decrypt
Log of positive ACK
Date/Time
Message ID
MSA-1 Value
Process for dealing with non-ACK/Timeout
Valid processes:
Re-transmit
Alert Management
Log Review
4.8.3 Report receiver (transport)
4.8.3.1 Receipt of message (ORU^R01^ORU_R01)
TABLE 14
TABLE OF RECEIPT EVALUATION
REQUIREMENTS
Receipt of Report Message (ORU^R01^ORU_R01)
Decrypt
If ACK used, commit to non-volatile storage
Pass message to Report Processor (correct for message type)
106747852 - 06/03/2016 7:21:12
DRAFT ONLY
DRAFT ONLY
16
DRAFT ONLY
4.8.3.2 Create accept acknowledgement (ACK)
TABLE 15
TABLE OF RECEIPT EVALUATION OF VALUES FOR REQUIRED FIELDS
Atomic Data
Fields
Value
MSH
MSH-1
Field Separator
|
MSH-2
Encoding Characters
^~&\
MSH-3
Sending Application
MSH-4
Sending Facility
MSH-7
Date/Time of Message
MSH-9
Message Type
MSH-10
Message Control ID
MSH-11
Processing ID
P
MSH-12
Version ID
2.3.1^AUS&Australia&ISO3166-1
ACK
MSA
MSA-1
Acknowledgement Code
MSA-2
Message Control ID
ERR
ERR-1
Error Code and Location
4.8.3.3 Deliver acknowledgement messages (ACK & ACK^R01)
TABLE 16
TABLE OF DELIVERY EVALUATION
REQUIREMENTS
Deliver Messages
ACK (To Report Deliverer - Transport)
ACK^R01 (To Report Deliverer)
With Fidelity
To Correct Address
Encryption
Security
Traceability
106747852 - 06/03/2016 7:21:12
Verified
DRAFT ONLY
17
DRAFT ONLY
4.8.4 Report processor
4.8.4.1 Receipt of Report Message (ORU^R01^ORU_R01)
TABLE 17
TABLE OF RECEIPT EVALUATION
REQUIREMENTS
Receipt of Report Message (ORU^R01^ORU_R01)
Parse Message
Process Content
Patient Match
Registered Patient
Non-Registered Patient
Commit content (atomic data) to non-volatile storage (to correct patient)
Commit message to non-volatile storage
Log receipt of message
4.8.4.2 Atomic Data
TABLE 18
TABLE OF EVALUATION OF PROCESSING OF REQUIRED FIELDS
Process or
Display
Fields
Value
Verified
MSH
P
MSH-1
Field Separator
|
P
MSH-2
Encoding Characters
^~&\
P
MSH-3
Sending Application
P&D
MSH-4
Sending Facility
P&D
MSH-5
Receiving
Application
P
MSH-7
Date/Time of
Message
P
MSH-9
Message Type
MSH10
Message Control ID
P
MSH11
Processing ID
P
MSH12
Version ID
P
P
MSH15
Accept
Acknowledgement
Type
AL(for Enhanced Mode)/NE (for
Original Mode)
P
MSH16
Application
Acknowledgement
Type
AL
ORU^R01^ORU_R01
P
2.3.1^AUS&Australia&ISO3166-1
PID
(continued)
106747852 - 06/03/2016 7:21:12
DRAFT ONLY
18
DRAFT ONLY
TABLE 18 (continued)
Process or
Display
Fields
Value
P&D
PID-3
Patient Identifier
List
P&D
PID-5
Patient Name
P&D
PID-7
Date/Time of Birth
P&D
PID-8
Sex
P&D
PID-11
Patient Address
PV1 (Optional)
P&D
PV1-2
Patient Class
P&D
PV1-8
Referring Doctor
P&D
PV1-9
Consulting Doctor
ORC
P
ORC-1
Order Control
P&D
ORC-3
Filler Order Number
P
ORC-5
Order Status
OBR
P
OBR-1
Set ID
P&D
OBR-3
Filler Order Number
P&D
OBR-4
Universal Service
ID
P&D
OBR13
Relevant Clinical
Info
OBR25
Result Status
P&D
OBR28
Result Copies To
P&D
OBX
P
OBX-2
Value Type
P&D(Unless a
LOINC
Comment
Code - see
3.5.1)
OBX-3
Observation
Identifier
P&D
OBX-5
Observation Value
P&D
OBX-6
Units
P&D
OBX-7
Reference Range
P&D
OBX-8
Abnormal Flags
P&D
OBX11
Observation Result
Status
P&D
OBX14
Date/Time of
Observation
106747852 - 06/03/2016 7:21:12
Verified
DRAFT ONLY
19
DRAFT ONLY
TABLE 19
TABLE OF EVALUATION OF SUPPORTED
DISPLAY SEGMENT TYPES
Display Formats—Validate any formats supported
HTML
XML
PIT
TXT
RTF
PDF
JPG
4.8.4.3 Creation of Application ACK (ACK^R01)
TABLE 20
TABLE OF EVALUATION OF VALUES FOR REQUIRED FIELDS
Atomic Data Fields
Value
MSH
MSH-1
Field Separator
|
MSH-2
Encoding Characters
^~&\
MSH-3
Sending Application
MSH-4
Sending Facility
MSH-7
Date/Time of Message
MSH-9
Message Type
MSH-10
Message Control ID
MSH-11
Processing ID
P
MSH-12
Version ID
2.3.1^AUS&Australia&ISO3166-1
ACK
MSA
MSA-1
Acknowledgement Code
MSA-2
Message Control ID
ERR
ERR-1
Error Code and Location
*** END OF DRAFT ***
106747852 - 06/03/2016 7:21:12
Verified