This
page
is
part
of
the
FHIR
Specification
(v0.0.82:
DSTU
1).
The
current
version
which
supercedes
this
version
is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
?.?
Purpose
The
FHIR
USLab
Report
Implementation
focuses
on
identifying
the
requirements,
specifications
and
standards,
and
on
providing
the
implementation
guidance
for
reporting
of
laboratory
test
results
to
ambulatory
care
providers
in
the
US
Realm
using
the
FHIR
in
the
RESTful
framework
.
Its
scope
includes
requirements
to
enable
the
incorporation
of
clinical
laboratory
test
results
into
an
Electronic
Health
Record
System
(EHR-S)
as
standardized
structured
data
using
the
defined
inter-organizational
laboratory
transaction.
The
Use
Case
requirements
are
directed
at
laboratory
test
results
reporting
between
a
Laboratory
Information
System
(LIS)
and
an
ambulatory
EHR-S
in
different
organizational
entities,
e.g.,
different
corporate
structure,
ownership
or
governance.
Future
versions
of
this
implementation
may
harmonize
with
existing
guides
to
extend
interoperability
of
laboratory
results
across
care
settings,
e.g.,
acute
care
and
public
health.
?.?
Audience
This
guide
is
designed
for
use
by
analysts
and
developers
who
require
guidance
on
FHIR
resources,
elements
and
specific
extensions
relative
to
the
Laboratory
Orders
Interface
(LOI)
initiative
and
the
HL7
V3
Lab
Normative
Standard.
Users
of
this
guide
must
be
familiar
with
the
details
of
the
FHIR
Specification
and
resource
processing.
This
guide
is
not
intended
to
be
a
tutorial
on
that
subject.
?.?
Conventions
This
guide
adheres
to
the
following
conventions:
-
The
guide
is
constructed
assuming
the
implementer
has
access
to
the
FHIR
Specification.
Although
some
information
from
the
standard
is
included
in
this
implementation
guide,
much
information
from
the
standard
has
not
been
repeated
here.
-
The
guide
is
constructed
assuming
the
implementer
SHALL
conform
to
the
FHIR
RESTful
API
-
The
rules
defined
in
the
FHIR
Conformance
Profile
were
used
to
document
the
use
case
for,
and
constraints
applied
to,
the
resources
described
in
this
guide.
?.?
Key
Technical
Decisions
?.?.1
Profile
And
Component
Architecture
This
guide
uses
FHIR
profiles
on
the
following
resource
to
define
a
minimum
set
of
requirements
to
enable
the
successful
exchange
of
laboratory
orders:
-
DiagnosticOrder
-
DiagnosticReport
-
Organization
-
Media
-
Organization
-
Patient
-
Practitioner
-
Specimen
The
main
objective
is
to
ensure
that
EHR
systems
and
Laboratory
systems
can
exchange
laboratory
orders
with
minimum
if
any
modifications
from
one
combination
to
another
combination
of
software,
while
maintaining
flexibility
to
enable
software
developers
to
provide
more
capabilities
using
the
same
core
Resource
definitions.
?.?.2
Use
Of
Vocabulary
Standards
This
guide
calls
for
specific
vocabulary
standards
for
the
exchange
of
laboratory
information
such
as
LOINC
and
SNOMED.
Standard
vocabularies,
particularly
coded
laboratory
tests
and
their
results,
enable
automated
decision
support
for
patient
healthcare,
as
well
as
for
public
health
surveillance
of
populations.
Value
Sets
resource
are
provided
as
part
of
this
implementation.
?.?.3
Snapshot
Mode
FHIR
only
functions
using
snapshot
mode
-
updates
are
communicated
by
sending
a
complete
copy
of
the
instance
with
the
new
data
filled
in.
If
a
correction
and/or
status
update
to
Obsveration
Resource
is
necessary,
the
DiagnosticReport
with
all
references
to
all
Obsveration
Resource,
even
if
previously
sent,
shall
be
resent
with
the
correction
and/or
current
status
and/or
current
values.
For
example,
when
a
Complete
Blood
Count
with
manual
differential
is
ordered,
the
blood
count
will
be
released
and
then
at
a
later
time
the
manual
differential
will
be
performed
and
released.
When
the
blood
count
is
released
the
DiagnosticReport
will
reference
only
the
Observation
Resources
for
the
count
as
final
results.
When
the
differential
is
completed,
the
DiagnosticReport
will
reference
all
previous
Observation
Resources
as
well
as
the
new
Observation
resources
-
in
this
case
the
blood
count
and
the
differential
results.
-->
?.?.4
Scope
Of
Implementation
Due
to
receiving
system
variations
and
need,
this
guide
does
not
specifically
indicate
for
each
field
whether
to
store
it
or
not.
This
is
left
to
the
individual
system's
scope
and
purpose.
?.?
Use
Case
-
Ambulatory
Care
Setting
This
use
case
was
developed
as
a
collaborative
effort
between
the
HHS/ONC
Standards
and
Interoperability
Framework
Laboratory
Results
Initiative,
the
California
Health
Care
Foundation,
and
the
HL7
Orders
and
Observations
Work
Group.
?.?.1
Scope
The
scope
is
the
sending
of
lab
results
from
a
laboratory
to
an
ambulatory
provider.
?.?.1.1
In
Scope
-
Defining
the
core
data
elements
required
for
ambulatory
care
clinical
laboratory
test
results.
-
Reporting
of
clinical
laboratory
test
results
for
ambulatory
care
in
the
US
Realm.
-
Sending
clinical
laboratory
test
results
as
standardized
structured
data
so
they
can
be
incorporated
that
way
into
an
EHR-S.
-
Reporting
test
results
for
an
order
that
was
placed
either
manually
or
electronically.
-
Some
order
specific
data
has
been
included
to
enable
the
receiving
EHR-S
to
correlate
the
results
back
to
the
originating
order.
-
Covering
all
CLIA
reporting
requirements
.
-
Receiving
of
laboratory
results
as
a
non-order
placer.
?.?.1.2
Out
of
Scope
-
Specifications
and
implementation
guidance
on
laboratory
ordering
transactions.
(
see
USLabOrder
-
Querying
for
laboratory
results.
-
Querying
for
historical
laboratory
results.
-
Receiving
historical
laboratory
results.
-
Secondary
use
of
laboratory
data
(i.e.,
public
health
or
bio
surveillance
uses
of
the
reported
laboratory
results).
-
In
hospital
ordering
and
reporting
of
laboratory
results.
?.?
Actors
There
are
two
actors
that
have
responsibilities
related
to
the
conformance
profiles
defined
in
this
document:
-
Laboratory
Report
Sender
-
The
originator
of
the
DiagnosticReport
Resource
Instance
that
declares
conformance
to
"RESTful
FHIR"
and
FHIR
profiles
defined
in
this
guide.
This
actor
is
the
Organization
Resource
referenced
through
the
.performer
(Organization)
Resource
within
FHIR.
-
Laboratory
Report
Receiver
-
The
receiver
of
the
DiagnosticReport
Resource
Instance
that
declares
conformance
to
"RESTful
FHIR"
and
FHIR
profiles
defined
in
this
guide.
This
actor
is
implied
within
FHIR.
(
i.e.
not
explicitly
referenced
in
the
DiagnosticReport
Resource
Instance
or
the
linked
resources).
?.?
Orders
for
Ambulatory
Care
Use
Case
and
Context
Diagrams
Figure
2-1.
Use
Case
Diagram
Figure
2-2.
Context
Diagram
?.?.1
User
Story
A
Provider
(orderer)
may
enter
a
laboratory
order
into
an
ambulatory
EHR-S.
A
laboratory
requisition
is
generated
(paper
or
electronic)
and
is
communicated
to
the
laboratory.
The
information
in
the
laboratory
requisition
is
entered
manually
or
captured
electronically
into
the
LIS.
After
the
specimen(s)
has
been
collected
and,
if
necessary,
shipped
or
delivered
to
the
laboratory,
the
laboratory
processes
the
specimen(s).
If
the
specimen
is
satisfactory
for
testing
the
laboratory
will
perform
the
test.
Prior
to
successful
completion
of
a
test,
communication
may
also
be
necessary
to
indicate
cancellation,
failure
to
perform
the
test
and
the
related
reasons;
for
example
if
the
specimen
is
either
not
appropriate
for
the
ordered
test,
or
otherwise
unsatisfactory
the
rejection
of
the
specimen
will
be
communicated
using
USlabReport
profile.
Order
cancellation
notifications
should
be
communicated
using
the
USLabOrder
profile.
The
laboratory
performs
or
attempts
to
perform
the
test(s).
If
testing
is
successful,
results
are
obtained
and
entered/released
in
the
LIS.
An
authorized
person
at
the
laboratory
reviews
and
approves
the
laboratory
test
results,
or
the
certifying
laboratory
reviewer
of
record
in
the
case
of
an
auto-verification
process,
to
be
sent
to
the
provider
and
any
non-ordering
providers
requested
in
the
laboratory
order.
The
results
are
either
pushed
or
pulled
into
the
provider's
EHR-S
(results
receiver).
The
EHR-S
incorporates
the
results
into
the
patient's
electronic
record.
The
provider
logs
into
his/her
EHR-S
and
views
the
laboratory
results
in
order
to
inform
patient
care
decisions.
?.?.1.1
Use
Case
Assumptions
-
Providers
securely
access
clinical
information
through
an
EHR-S.
-
Appropriate
security
and
transport
protocols;
patient
identification
methodology;
requisition
(order)
identification
methodology;
consent;
privacy
and
security
procedures;
coding,
vocabulary
and
normalization
standards
have
been
agreed
to
by
all
relevant
participants.
-
This
Use
Case
only
addresses
the
exchange
of
laboratory
results
that
are
associated
with
the
In
Scope
laboratory
tests.
-
This
Use
Case
covers
all
CLIA
reporting
requirements
-
For
the
specimen
collection
process
the
data
included
in
the
dataset
considerations
table
6
are
assumed
to
be
available
and
reported
in
the
result.
-
Legal
and
governance
issues
regarding
data
access
authorizations,
data
ownership,
and
data
use
are
in
effect.
-
Established
network
and
policy
infrastructure
to
enable
consistent,
appropriate,
and
accurate
information
exchange
across
provider
systems,
data
repositories
and
locator
services.
This
includes,
but
is
not
limited
to:
-
Methods
to
identify
and
authenticate
users;
-
Methods
to
identify
and
determine
Providers
of
care;
-
Methods
to
enforce
data
access
authorization
policies;
-
Methods
to
ensure
the
veracity
of
data;
-
Detailed
audit
trails
are
kept
as
necessary
by
all
participating
systems.
-
Security
and
privacy
policies,
procedures
and
practices
are
commonly
implemented
to
support
acceptable
levels
of
patient
privacy
and
security;
i.e.
HIPAA,
HITECH
and
EHR
certification
criteria.
-
A
LIS
will
be
the
source
of
laboratory
test
results
while
an
EHR
will
be
the
recipient.
-
This
Use
Case
acknowledges
the
variations
in
requirements
for
reporting
across
local,
state,
tribal,
and
territorial
boundaries
as
well
as
voluntary
versus
mandatory
requirements.
-
Laboratories
meet
accreditation
criteria
according
to
jurisdiction
requirements
or
agency
criteria.
?.?.1.2
Pre-Conditions
-
An
order
has
been
generated
by
an
Ordering
Provider
for
one
or
more
laboratory
tests
results
to
be
produced.
-
When
indicated,
the
Laboratory
receives
request
to
send
laboratory
results
to
a
non-order
placer.
-
The
Laboratory
receives
an
order
(electronic,
paper,
etc.)
or
the
Laboratory
receives
a
request
to
re-run
(repeat)
a
test,
or
determines
a
need
to
re-run
a
test
for
possible
correction,
or
determines
that
reflex
testing
(which
is
based
on
criteria
set
by
the
medical
review
board)
is
required
or
determines
the
need
to
amend
a
test
result
based
on
erroneous
information.
-
The
Laboratory
receives
the
appropriate
clinical
information
to
perform
the
ordered
test.
-
Laboratory
has
entered
manually
or
through
the
interface
pertinent
(or
corrected)
data
from
an
order
into
the
LIS
-
Laboratory
has
received
and
processed
properly
identified
specimen(s)
related
to
the
ordered
test(s).
-
Laboratory
entered
or
received
from
the
ordering
EHR-S,
pertinent
data
from/about
the
specimen
into
the
LIS.
-
Laboratory
performed
the
ordered
tests
on
received
specimens
and/or
incorporated
calculated
and
reference
data
to
produce
the
results
to
be
exchanged.
-
The
laboratory
DiargnosticReport
resource
refers
to
the
appropriate
Patient
resource
and
DiagnosticOrder
resource
to
associate
the
laboratory
results
to
the
correct
patient
and
original
order.
-
The
LIS
is
capable
of
and
ready
to
send
laboratory
results
using
FHIR
and
REST
and
standardized
structured
data
format.
-
EHR-S
is
in
place
and
capable
of
receiving
laboratory
results
using
FHIR
and
REST
and
standardized
structured
data
format.
-
The
laboratory
result
is
verified
and
ready
for
release.
?.?.1.3
Post-Conditions
-
Laboratory
results
are
accurately
reported
and
successfully
transmitted
electronically
from
the
LIS
to
the
Ordering
Provider's
(order
placer's)
EHR-S,
module
or
other
results
receiver.
-
The
provider's
EHR-S
has
electronically
received
the
laboratory
results,
incorporated
in
a
standardized
structured
format,
and
if
available,
associated
with
a
patient
and
laboratory
order.
?.?.1.4
Functional
Requirements
todo
?.?.1.4.1
Sequence
Diagram
Figure
N-N:
Scenario
1
Sequence
Diagram
?.?
Error
Handling
Refer
to
the
FHIR
Specification
on
REST
status
codes
and
the
use
of
the
OperationOutcome
Resource
when
further
information
about
the
transaction
error
is
needed.
Note
to
balloters:
The
error
handling
specifications
are
currently
not
fully
defined
for
this
implementation.
?.?
Code
Systems
And
Value
Sets
Successful
message
implementation
requires
that
transmitted
messages
(message
instances)
contain
valid
values
for
coded
fields.
For
further
discussion
on
Using
codes
in
FHIR
refer
to
the
FHIR
specification.
?.?.1
LOINC
The
use
of
the
Logical
Observation
Identifiers
Names
and
Codes
(LOINC)
code
system
is
required
where
a
LOINC
code
is
available
for
the
Observation.name,
i.e.
the
being
resulted.
Appropriate
status
is
defined
in
the
LOINC
Manual
Section
11.2
Classification
of
LOINC
Term
Status.
If
a
local
coding
system
is
in
use,
a
local
code
should
also
be
sent
in
addition
to
the
LOINC
to
help
with
identification
of
coding
issues.
When
no
valid
LOINC
exists
the
local
code
may
be
the
only
code
sent.
While
data
storage
requirements
in
the
EHR
will
not
be
addressed
in
this
guide,
it
is
recommended
that
LOINC
codes
be
stored
in
or
accessible
by
the
EHR
for
the
following
reasons:
-
If
the
result
is
related
to
a
reportable
condition
and
the
laboratory
provides
a
LOINC
code,
-
Meaningful
Use
Stage
requires
the
EHR
to
send
the
LOINC
code
to
public
health.
If
the
LOINC
code
is
the
only
code
sent
to
the
lab
in
OBX-3,
then
the
EHR
must
store
and
retain
that
code
to
satisfy
CLIA
reporting
requirements.
-
LOINC
codes
may
be
used
for
secondary
data
exchange
purposes
and
other
partner
exchange
agreements.
?.?.2
SNOMED
CT
The
use
of
the
SNOMED-CT
code
system
is
required
where
a
SNOMED-CT
concept
code
is
available
for
Observation.valueCodeableConcept,
i.e.
the
actiual
coded
result.
If
a
local
coding
system
is
in
use,
a
local
code
should
also
be
sent
in
addition
to
the
SNOMED-CT
concept
code
to
help
with
identification
of
coding
issues.
When
no
valid
SNOMED-CT
exists
the
local
code
may
be
the
only
code
sent.
to
satisfy
CLIA
reporting
requirements,
It
also
recommended
that
the
Observation.valueCodeableConcept.text
element
is
used
if
laboratory's
original
text
which
is
used
for
printing
and/or
display
is
different
from
the
code
display
value.
SNOMED
CT
is
required
for
specimen
source
term
elements,
Specimen.type
and
Specimen.Collection.sourceSite
where
a
SNOMED-CT
concept
code
is
available.
?.?.3
UCUM
The
use
of
the
UCUM
(Unified
Code
for
Units
of
Measure)
code
system
is
required
for
reporting
units
of
measure
in
Observation.quantity.
?.?.4
Value
Sets
The
value
sets
for
this
implementation
as
well
as
USLabOrder
and
USLabPHReport
can
be
found
on
the
USlab
Implementation
page
.
In
additionm,
mappings
to
the
HL7
Version
2.5.1
Implementation
Guide:
S&I
Framework
Lab
Results
Interface
are
also
available.
?.?
Additional
Implementation
Guidance
?.?.1
Confirmatory
and
Reflex
Testing
(
Including
Culture/Susceptibility
Testing)
Definition:
Additional
laboratory
testing
included
in
the
original
test
request
by
reference
to
specific
follow-up
testing,
e.g.
"Urinalysis
w/Culture
Reflex"
as
opposed
to
"Urinalysis"
ordered
as
a
standalone
test.
The
decision
to
perform
the
reflex
or
confirmatory
test
is
based
upon
the
results
of
the
initial
test
and
application
of
a
predetermined
local
or
national
practice
guideline,
approved
protocol
or
legal
requirement.
-
Example:
A
Urinalysis
with
elevated
WBCs
signals
the
potential
for
bacterial
infection
and
a
confirmatory
Urine
Culture
is
ordered
on
the
same
specimen
as
a
reflex
test.
Depending
on
the
laboratory
standard
operating
procedure,
LIS
and
nature
of
the
reflexed
or
confirmatory
test
one
or
more
of
the
following
may
be
generated:
a
new
accession
number,
new
test
codes
and
additional
charges.
-
CLIA
Compliance:
The
initial
test
request
received
in
the
laboratory
is
adequate
to
demonstrate
an
order
for
both
the
initial
and
the
additional
testing
for
CLIA
compliance
and
CMS
auditing
purposes.
-
LIS
Process:
The
LIS
shall
report
the
reflexed
test
as
one
of
the
following:
-
Additional
results
within
the
same
DiagnosticReport.referencing
the
same
DiagnosticOrder
from
the
original
order
request
in
the
DiagnosticReport.requestDetail
element
-
One
or
more
additional
DiagnosticReports
referencing
the
same
DiagnosticOrder
from
the
original
order
request
in
the
DiagnosticReport.requestDetail
element
-
One
or
more
additional
DiagnosticReports
referencing
a
new
DiagnosticOrder
from
add-on
order
request
and
the
DiagnosticOrder
from
the
original
order
request
in
the
DiagnosticReport.requestDetail
element
An
example
is
provided
here
for
the
scenario
in
which
a
urine
cultire
results
in
the
identification
of
the
pathogens:
E.coli,
x
and
y
and
a
susceptibilty
is
performed
on
all
three
pathogens.
todo..
?.?.2
Add-On
Testing
Definition:
Additional
laboratory
testing
is
requested
by
an
authorized
provider
(as
defined
by
CLIA
and
state
law)
on
an
existing
specimen
after
the
original
test
request
has
been
submitted
to
the
laboratory.
The
decision
to
request
additional
testing
is
individual
provider
driven
and
based
on
any
number
of
factors
not
limited
to
a
test
result.
-
Example:
A
physician
orders
a
Complete
Blood
Count
and
Basic
Metabolic
Panel
on
an
outpatient
who
presented
in
the
office
with
symptoms
of
fatigue
and
a
low-grade
fever
following
a
camping
trip
to
Wisconsin.
After
consultation
with
an
infectious
disease
physician
later
in
the
day,
he
calls
the
laboratory
and
requests
the
addition
of
a
Lyme's
Disease
Antibody
test
to
the
specimens
already
in
the
laboratory.
-
CLIA
Compliance:
CLIA
requires
the
laboratory
to
obtain
a
written
or
electronic
test
request
for
the
add-on
testing
from
the
authorized
provider
for
its
records.
If
the
test
request
is
verbal
the
laboratory
must
document
its
efforts
to
receive
a
written
or
electronic
test
request
within
30
days.
[§42CFR493.1241(b)]
-
LIS
Process:
The
LIS
shall
report
the
reflexed
test
as
described
above
:
?.?.3
Clinical
Laboratory
Improvement
Amendments
Considerations
In
the
United
States,
clinical
laboratory
testing
of
human
specimens
is
regulated
by
the
Clinical
Laboratory
Improvements
Amendments
of
1988
(CLIA).
Several
sections
of
the
regulations
implementing
CLIA
impact
how
electronic
laboratory
data
is
formatted
for
the
US
Realm
and
these
are
outlined
in
this
section.
Impacted
areas
include
mandatory
test
request
requirements.
CLIA
Regulation
Specifics
.
?.?.4
Mandatory
Ordering
Requirements
Section
493.1241
of
the
CLIA
Regulations
requires
the
laboratory
to
have
a
written
or
electronic
request
for
patient
testing
from
an
authorized
person,
and
defines
items
that
must
appear
as
part
of
a
clinical
laboratory
test
request
.
The
laboratory
may
accept
oral
requests
for
laboratory
tests
if
it
solicits
a
written
or
electronic
authorization
within
30
days
of
the
oral
request
and
maintains
the
authorization
or
documentation
of
its
efforts
to
obtain
the
authorization.
Interpretative
guidelines
on
the
elements
required
in
a
test
requisition
.
Specific
fields
impacted
include
the
following:
|
FHIR
element
|
CLIA
Requirement.
|
|
Patient.identifier
|
A
unique
patient
identification
number
is
required
|
|
Patient.name
|
The
patient's
name
or
unique
patient
identifier.
|
|
Observation.name
|
Unique
identification
of
the
test
performed
is
required.Use
of
LOINC
codes
for
additional
tests
is
strongly
encouraged.
For
certain
tests
CLIA
requires
additional
information:
Laboratories
using
manufacturer's
instruments,
kits
or
test
systems
labeled
for
"investigational
use
only"
or
"research
use
only"
must
clearly
state
that
the
test
results
are
not
to
be
used
for
treatment
or
diagnostic
purposes.
If
results
of
such
tests
are
being
reported
without
a
disclaimer
statement,
or
are
being
used
by
the
provider
for
patient
care,
they
are
in
the
same
category
as
in-house
developed
tests
and
the
laboratory
must
establish
performance
specifications
in
accordance
with
�493.1253.
The
disclaimer
for
Analyte
Specific
Reagents
(ASR)
should
state,
"This
test
was
developed
and
its
performance
characteristics
determined
by
(Laboratory
Name).
It
has
not
been
cleared
or
approved
by
the
U.S.
Food
and
Drug
Administration."
The
ASR
disclaimer
on
the
test
report
is
required
by
the
FDA
under
21
CFR,
Part
809.30,
"Restrictions
on
the
sale,
distribution
and
use
of
analyte
-specific
reagents."
|
|
Observation.value
|
The
laboratory
result
is
required.
No
regulatory
requirements
are
specified,
outside
of
readability,
regarding
result
appearance.
|
|
Observation.valueQuantity
|
Units,
if
required,
or
an
interpretation
must
be
given.
For
tests
such
as
genetic
screens
the
interpretation
may
actually
be
the
test
result.
UCUM
for
vocabulary
use
is
preferred.
|
|
Observation.interpretation
|
Units,
if
required,
or
an
interpretation
must
be
given.
For
tests
such
as
genetic
screens
the
interpretation
may
actually
be
the
test
result.
|
|
Observation.referenceRange
|
When
available
reference
range
shall
be
valued.
|
|
DiagnosticReport.status
|
Used
to
reflect
CLIA
required
conditions
such
as
specimen
acceptability,
result
corrections,
cancellations
as
well
as
report
status
(§493.1291
(c)(7)
and
(k)(1,2).
|
|
Observation.issued
|
This
field
is
used
to
transfer
the
time
stamp
associated
with
generation
of
the
analytical
result
by
the
instrument
specified
in
Equipment
Instance
Identifier.
|
|
DiagnosticReport.performer(Organization)
|
The
identification
of
the
performing
laboratory
is
required.
Populated
with
the
CLIA
ID
Number.
If
the
CLIA
ID
number
is
not
used,
all
demographic
fieldsmust
be
provided
with
appropriate
information.
|
|
Specimen.type
|
Reporting
requirements
call
for
the
specimen
source,
which
equates
at
minimum
to
the
Specimen
Type
|
|
Observation.UnsatisfactorySpecimenReason
(extension)
|
To
specify
the
reason
for
specimen
rejection..
|
?.?.5
CLSI
Definitions
-
Quantitative,
Semi-quantitative,
Qualitative
Results
The
following
defnitions
were
derived
from
the
CLSI
website:
-
QUANTITATIVE
-
A
characterization
applied
to
laboratory
tests
that
give
results
expressing
a
numerical
amount
or
level
(concentration)
of
an
analyte
in
a
specimen;
NOTE
1:
It
is
usually
compared
to
an
accredited
recognized
standard;
NOTE
2:
This
is
in
contrast
to
qualitative
tests.
-
When
used
to
describe
a
test,
means
a
test
that
produces
a
result
that
is
numerical.
For
example,
a
point-of-care
blood
glucose
test
might
generate
a
result
of
120
mg/dL
(1.20
g/L).
In
contrast,
a
qualitative
test
generates
a
non-numerical
result
such
as
'positive'
or
'detected.'
A
subset
of
quantitative
tests
called
semiquantitative
provides
results
either
over
a
range
of
values,
such
as
a
urine
dipstick
that
results
in
glucose
ranges
of
0-40,
40-100,
and
>100
mg/dL
(0-0.4,
0.4-1,
and
>1
g/L),
or
as
a
series
of
relative
values,
such
as
the
same
multiple
test
urine
dipstick
that
results
in
hemoglobin
as
0,
+,
++,
+++,
and
++++.
-
QUALITATIVE
-
When
used
to
describe
a
test,
means
a
test
that
produces
a
result
that
is
descriptive
rather
than
numerical.
For
example,
a
urine
pregnancy
test
might
generate
a
result
of
'positive'
or
'negative'
for
urinary
hCG.
In
contrast,
a
quantitative
test
generates
a
numerical
result.
The
quality
control
and
reporting
procedures
differ
significantly
for
quantitative
and
qualitative
tests.
-
Characterization
applied
to
laboratory
tests
that
detect
and/or
identify
a
particular
analyte,
constituent,
or
condition;
NOTE
1:
This
term
is
applied
to
tests
that
detect
whether
a
particular
analyte,
constituent,
or
condition
is
present
or
absent,
and
is
sometimes
assigned
a
positive
degree
(ie,
1+,
2+);
NOTE
2:
It
may
also
be
called
semiquantitative
tests;
NOTE
3:
Specific
identification
may
be
performed.
-
SEMI-QUANTITATIVE
-
A
test
that
has
a
dose-response
gradient
that
may
be
included
in
the
reported
result,
but
for
which
no
authorative
calibration
scale
exists
to
determine
inaccuracy
and
imprecision;
tests
that
yield
results
in
an
approximate
range
of
values
(e.g.,
trace,
moderate);
NOTE:
This
definition
includes
tests
with
subjective
readout
of
quantification
such
as
IF-ANA
titers,
and
it
includes
tests
with
an
instrumental
readout
of
quantification
such
as
ELISA-ANA
when
the
instrument
scale
cannot
be
referenced
to
an
authoritative
calibration
scale.
-
Tests
that
yield
results
in
an
approximate
range
of
values
(e.g.,
trace,
moderate).
?.?.6
Glossary
-
Analyte:
Component
represented
in
the
name
of
a
measurable
quantity.
It
is
the
most
granular
level
at
which
measurements
are
made
and
always
represented
using
a
single
Observation
segment
group
-
Cancellation:
Act
of
cancelling
the
order.
-
Electronic
Health
Record:
Clinical
information
for
a
specific
patient
that
is
stored
electronically
within
an
EHR-S.
Electronic
Health
Record
System
(EHR-S)
This
IG
uses
this
term
in
the
same
context
as
stated
in
the
"HL7
EHR
System
Functional
Model
White
Paper"
Section
4
Definitions
(HL7
2004
www.hl7.org):
"It
is
important
to
note
that
the
DSTU
does
not
attempt
to
establish
another
definition
for
EHR
Systems,
but
chooses
to
utilize
existing
definitions
that
include
the
concept
of
EHR
Systems
as
a
system
(at
least
one)
or
a
system-of-
systems
that
cooperatively
meet
the
needs
of
the
end
user."
-
Future
Order:
A
future
order
is
an
order
with
a
start
date/time
where
that
start
date/time
indicates
the
earliest
time
the
specimen
can
be
collected.
-
Laboratory:
A
facility
or
organization
that
performs
laboratory
testing
on
specimens
for
the
purpose
of
providing
information
for
the
diagnosis,
prevention,
treatment
of
disease
or
impairment,
or
assessment
of
health
for
humans.
Laboratory
Information
System
(LIS)
An
information
system
that
receives,
processes,
and
stores
information
related
to
laboratory
processes.
LIS
may
interface
with
HIS
and
EHR
applications.
This
definition
is
very
minimal
and
omits
many
features
and
capabilities
that
are
typically
associated
with
laboratory
information
systems.
This
minimal
characterization
is
intentional,
as
to
include
the
broadest
possible
set
of
LIS
systems
in
the
use
case.
The
minimal
nature
of
the
definition
by
no
means
excludes
LIS
with
significantly
greater
capabilities.
-
Laboratory
Order:
a
DiagnosticOrder
Resource
item
requesting
one
or
more
measurements
(Observation
Resources).
Synonymous
with
a
Requisition
when
referring
to
a
single
DiagnosticOrder
Resource
item.
-
Laboratory
Order
System:
Software,
either
stand-alone
or
as
part
of
an
EHR
system,
used
by
a
Provider
(Order
Placer)
to
manage
a
laboratory
order,
including
generating
the
laboratory
requisition
and
sending
it
to
a
laboratory.
Typically
a
laboratory
order
system
is
an
integral
part
of
an
order
management
system
that
enables
users
to
manage
orders
for
many
different
types
of
services,
procedures,
supplies,
etc.
Since
this
guide
only
focuses
on
data
exchange
relative
to
laboratory
orders
it
is
purposely
using
a
very
limited
definition.
-
Laboratory
Requisition:
A
set
of
information
that
constitutes
an
official
request
for
one
or
more
laboratory
tests
to
be
performed
on
an
individual
patient.
A
laboratory
requisition
is
specified
in
a
clinical
setting
and
communicated
to
a
laboratory
as
a
discrete
paper
or
electronic
artifact.
Laboratory
requisitions
always
include
at
least
one
test
order.
In
terms
of
a
FHIR
order
transaction
it
represents
one
or
more
DiagnosticOrders
Resource
item(s).
-
Newborn:
The
precise
cutoff
when
a
patient
is
considered
a
newborn
or
an
infant
is
subject
to
interpretation
and
this
guide
does
not
intend
to
provide
a
definitive
answer
to
that.
For
further
background
the
reader
is
directed
to
the
following
resources:
-
Orderable
Test:
A
request
to
perform
an
individual
test
or
panel.
It
always
refers
to
a
single
DiagnosticOrder
Resource
item.
and
may
have
one
or
more
associated
analytes
(bservations).
-
Panel:
While
there
are
differences
in
the
meanings
of
the
terms
"panel"
among
various
laboratories,
for
the
purposes
of
this
guide,
it
is
defined
as
a
grouping
of
procedures
that
measure
multiple
analytes
from
a
single
specimen
(or
multiple
specimens
in
some
cases)
and
can
be
requested
through
one
laboratory
order.
This
is
also
referred
to
as
a
battery.
For
example,
a
CBC
or
a
urinalysis
may
be
referred
to
as
a
panel.
-
Order
Set:
A
set
of
laboratory
orders
that
involve
multiple
tests
and
panels
and
that
may
require
multiple
specimens,
but
can
be
requested
as
a
single
unit
for
convenience.
For
example,
a
"diabetic
order
set
profile"
might
include
a
CBC,
a
glycosylated
hemoglobin
test,
and
a
urinalysis.
The
term
"panel"
is
frequently
used
interchangeably
with
"order
set",
thus
an
order
set
profile
that
contains
a
variety
of
laboratory
test
orders
that
may
be
on
its
own
or
be
combined
with
other
test
orders
(e.g.,
radiology
image,
consult,
etc.)
can
be
considered
an
order
set.
Order
sets
shall
not
be
communicated
to
the
laboratory.
Request
for
Cancellation
(RFC)
Request
by
the
Provider
(Order
Placer)
not
to
perform
the
order.
-
Test:
A
medical
procedure
or
named
set
of
related
procedures
that
involves
analyzing
one
analyte
using
a
single
sample
of
blood,
urine,
or
other
specimen
from
a
patient
for
the
purpose
of
diagnosing
a
disease
or
medical
condition,
planning
or
evaluating
treatment,
or
monitoring
the
course
of
a
disease.