Laboratory Request - tabular view

A laboratory request sent from a Service requestor to a laboratory Service provider to request laboratory investigations.

LaboratoryRequestGroup provides the focus act for all laboratory orders. The order is generally a single Order Group with one or more order components and uses the Act code to carry a generic term "Laboratory Request".

The specimen participation is generally with the Placer Group which is conducted down to all component orders. As such, the LaboratoryRequestGroup provides for a specimen centric order with multiple components. It also provides a mechanism for associating a LaboratoryRequestGroup Identifier with multiple order items.

In certain circumstances, this act may serve as a LaboratoryRequestGroup for specific multi-sample requests where the PlacerGroup is used for sub-requests. In no circumstances shall the act code carry a concept ID for an individual procedure/finding such as a Test or Battery. The target act of the LaboratoryRequestGroup may be a PlacerGroup or an ObservationRequest

Indicates that this is an act.

• Fixed value: "ACT"

Indicates that this is a request.

• Fixed value: "RQO"

A list of identifiers for this request.

The first (mandatory) identifier is a local identifier allocated by the originating system. It is made up of two parts, a root and extension. The Root will be an OID allocated to the system that generates the extension and will be at such a level that the combination of the Root and Extension is universally unique. The extension will be a human readable string generated by the system and may not be unique across the whole system.

< id root =" 9.99.999.99.10.2 " extension ="100993333 "/>

Where 9.99.999.99.10  identifies the Placer organization and 9.99.999.99.10.2 identifies the ID scheme within the Placer system that generated the extension B05.00504885C 

The second identifier is for possible future use

A SnomedCT code that describes the request. In normal use, the LaboratoryRequestGroup is used as a Grouper for multiple order items on a single sample and the Act.code shall be "SnCT ConceptID 24691000000102- laboratory request (administrative concept)". Only where the LaboratoryRequestGroup represents a specific multi-sample profile such as DFT, Creatinine clearance etc shall an appropriate different code from the SNOMED lab investigation subset_UK_20060401  be used and the specimens associated at a lower level.

This code shall never be a requested observation in its own right but is used to group other related requests

Shall be 'Active' unless the message is used in a Nullify interaction when it shall be 'Nullified'.

The effective time of the request. This is the date the the order should be processed which is generally the day the specimen is collected which triggers the sending of the request. In some situations, this may not be known at the time the order is placed. In these situations, an expected date the request will be actioned may be sent or a  Null flavour may be used.

The perceived priority of the request as seen by the placer. This is constrained to 'Routine' or 'Urgent'.

 Refers to the patient who is the subject of the request. 

The intended Performer fulfilling the request

Refers to the person or department responsible for authorising the  laboratory request. 

Intended additional recipients of the results

This is the subject of the requested investigation(s). Generally, this is a specimen originating from the patient. It may also be an Isolate obtained from a previous specimen.

This provides the mechanism by which additional information relevant to the request is carried.

Refers to a previous act that is being replaced by the current act.

NOTE:- This is not to be used for implementations within the current scope of the W5

Identifies the reason (generally clinical) for the request

Details of the patient.

Indicates that the role is that of a patient.

• Fixed value: "PAT"

The NHS number  that identifies the patient. Note that this may be issued as a temporary flavour.

NHS numbers are composed of ten numerics. All other formats shall be treated as temporary. This is the only way of differentiating between the two formats in this implementation.

The root element identifies the  NHS patient numbering scheme represented by OID 2.16.840.1.113883.2.1.4.1 and the extension contains the actual identifier.

Information about the person who is the identified patient.

Details about the patient

NPfIT CMET to identify an organization associated with the Report. Full details of the organization are available from SDS. Details of the scoping organization are either not required or available from SDS.

This CMET should only be used if an individual health care professional is not available.

Only the following Classes and Attributes from this CMET shall be included in this message.  Classes and attributes that are not detailed below are not to be used in this message.

AgentOrgSDS.id - shall carry a nationally agreed identifier for the role being played.  This shall be a code from a national coding scheme.

A national code is carried in the following way:

• The root attribute shall contain the OID that identifies the coding scheme.
• The extension attribute shall contain the code.

AgentOrgSDS.code - shall carry a code from the HL7 vocabulary RoleCode to identify the type of role that the agent is playing.

OrganizationSDS.id - shall carry a valid SDS identifier that uniquely identifies the Organization.   This could come from a number of SDS sets including (but not limited to) Organizations and Workgroups:

• The root attribute shall be the OID for the SDS code set
• The extension attribute shall contain the code.

NPfIT CMET to identify a person associated with the Report. Full details of the person and role profile are available from SDS.

This CMET should be used in preference to UKCT_MT120501UK03.

Only the following Classes and Attributes from this CMET shall be included in this message.  Classes and attributes that are not detailed below are not to be used in this message.

AgentPersonSDS.id shall  carry An SDS identifier that uniquely identifies the role of the Person in the following way:

• The root attribute shall contain an OID with the value 1.2.826.0.1285.0.2.0.67.
• The extension attribute shall contain the SDS Role Profile ID.

PersonSDS.id shall carry an SDS identifier that uniquely identifies the Person in the following way:

• The root attribute shall contain an OID with the value 1.2.826.0.1285.0.2.0.65.
• The extension attribute shall contain the SDS User ID.

The Laboratory Request Group may have one or more requested items or sub-orders, each with one or more requested items.

This provides the mechanism by which additional information relevant to the request is carried.

Identifies the reason (generally clinical) for the request

An individual Request item such as FBC, LFT, C&S etc

A group of requests on a specimen within the overall Laboratory request

References an act that is being replaced by the current 'new' act. This is not used in the current scope.

Any resending of the same report act superceded the previous.

Indicates that this is an act.

• Fixed value: "ACT"

Indicates that this is a request.

• Fixed value: "RQO"

Carries the locally allocated identifier of the Act from an earlier request that is being replaced.

Fixed as "Obsolete". All replaced acts are set to "Obsolete".

Details of the patient

Indicates that the entity is a person.

• Fixed value: "PSN"

Indicates that the entity is a single identifiable person.

• Fixed value: "INSTANCE"

To provide zero or more structured names of the patient.

Zero or one occurrence of the usual name may be provided.

Zero or more occurrences of alias names may also be provided.

Zero or one occurrence of a preferred name may also be provided.

The following sub-elements are used to carry components of a structured name:

• A single instance of the prefix element is used to carry a name title, for example, Mr, Mrs, Ms etc;
• One or more instances of the given element are used to carry given names (or forenames) or initials, with the order in which they are carried in the message being significant, i.e. the first occurrence of the given element is used to carry the first given name, the second occurrence of the given element is used to carry the second given name etc;
• A single instance of the family element is used to carry the family name (or surname);
• A single instance of the suffix element is used to carry a name prefix, for example, Jnr, Snr etc.

Where the usual name is being carried, this is required to be indicated with a value of "L" in the use attribute.

Where an alias name is being carried, this is required to be indicated with a value of "A" in the use attribute.

Where a preferred name is being carried, this is required to be indicated with a value of "PREFERRED" in the use attribute.

For the usual name type, the validTime sub-element may be used to indicate dates from and to which the name was/is to be effective, in the following way:

• The low sub-element of the validTime element may optionally be present with the date from which the name was effective provided in YYYYMMDD format in the value attribute;
• The high sub-element of the validTime element may optionally be present with the date to which the name was/is to be effective provided in YYYYMMDD format in the value attribute.

To provide the current registered sex of the patient in coded form.

The Coded Only datatype flavour is used to carry this information as follows:

• The code attribute will contain a value from the list of codes in the Sex vocabulary;

To provide the date the patient was born.

The date may be given in one of the following formats:

• YYYYMMDD where the full date of birth is known;
• YYYYMM or YYYY where the full date of birth is not known.

One of the Date Only or Date Month or Date Year datatype flavours is used to carry this information as follows:

• The value attribute will contain the date value in one of the formats indicated.

Carries the patient's home address.

An address is composed of the following components:

• Between one and five unstructured address lines;
• Postcode;

Other optional parts of AD data types are not required (e.g.. use, addressKey and usablePeriod).

• An effective from date may be provided for every address; an effective to date may also be provided for any address.

The first of these components is required to be present with any address.

The following sub-elements are used to carry the components of an address:

• Between one and five streetAddressLine elements are used to carry unstructured address lines, with the order in which they are carried in the message being significant, i.e. the first occurrence of the streetAddressLine element is used to carry the first line of address, the second occurrence of the streetAddressLine element is used to carry the second line of address etc;
• A postalCode element is used to carry a postcode;

The clinically significant Ethnicity of the patient. This is important in the interpretation of some results and may have reference ranges based upon it. It is not the ethnicity by which the patient chooses to be identified but the genetically significant parentage.

An discrete investigation or group of investigations requested by the placer. These will be fulfilled by the laboratory by the reporting of appropriate laboratory investigations in fulfillment of the requested items. The laboratory may perform different investigations than those requested in order to fulfill the request. One requested item may be fulfilled by multiple laboratory investigations. 

Indicates that this is an observation.

• Fixed value: "OBS"

Indicates that this is a request.

• Fixed value: "RQO"

A list of identifiers for this requested item.

The first (mandatory) identifier is a local identifier allocated by the originating system. It is made up of two parts, a root and extension. The Root will be an OID allocated to the system that generates the extension and will be at such a level that the combination of the Root and Extension is universally unique. The extension will be a human readable string generated by the system and may not be unique across the whole system.

< id root =" 9.99.999.99.10.2 " extension ="0001192992 "/>

Where 9.99.999.99.10  identifies the organization and 9.99.999.99.10.2 identifies the ID scheme within the system that generated the extension.

The second identifier is for possible future use

This is used to carry the order item (FBC, U&E, C&S etc). This is a required attribute and shall be populated with a concept ID from the national subset of Investigations (SNOMED lab investigation subset_UK_20060401)

Always 'Active' unless in a Nullify interaction when it shall be 'Nullified'

The time when the test is expected to be performed, or an appropriate nullFlavor (NI)

Constrained to "Routine" or "Urgent"

When the mesage is a specimen centric request, the specimen is carried at the top level and inherited by each requested observation.

The PlacerGroup provides a mechanism for a single LaboratoryRequestGroup to be made up of multiple specimen centric orders. This is not a common occurrence and use of this will not be common. Where this does occur, the specimen will be associated with the PlacerGroup rather than with the LaboratoryRequestGroup

Indicates that this is an act.

• Fixed value: "ACT"

Indicates that this is a request.

• Fixed value: "RQO"

A list of identifiers for this placer group.

The first (mandatory) identifier is a local identifier allocated by the originating system. It is made up of two parts, a root and extension. The Root will be an OID allocated to the system that generates the extension and will be at such a level that the combination of the Root and Extension is universally unique. The extension will be a human readable string generated by the system and may not be unique across the whole system.

< id root =" 9.99.999.99.10.2 " extension ="0001192992 "/>

Where 9.99.999.99.  identifies the Hospital organization and 9.99.999.99.10.2 identifies the ID scheme within the Laboratory system that generated the extension.

The second identifier is for possible future use

Where the PlacerGroup is used as a Grouper for multiple sub-orders, the Act.code shall represents a specific multi sample profile such as DFT, Creatinine clearance taken from SNOMED lab investigation subset_UK_20060401. It shall never be a specific investigation in its own right.

Shall be 'Active' unless the message is used in the Nullify interaction where it  shall be 'Nullified'

The time when the request is expected to be actioned. This may be a future time, if known or an appropriate nullFlavor (NI).

Constrained to "Routine" or "Urgent"

The subject of the investigations

A Placer Group must have 2 or more component ObservationRequests.

Stub act indicating patient care provision, to allow the responsible clinician to be carried.

Indicates that this is patient care provision.

• Fixed value: "PCPR"

Indicates that this is an event.

• Fixed value: "EVN"

Allows the patient's responsible clinician to be carried.

SupportingClinicalInformationChoice provides for the carriage of any clinical information in support of the request. This may be an observation, medical procedure, a clinical condition, substance administration etc.