Use to record details about a physical sample for investigation, examination or analysis, collected from or related to an individual.
This archetype has been specifically designed to be used in the three ways listed below, but can also be used within other ENTRY or CLUSTER archetypes, where clinically appropriate.
- Within an INSTRUCTION archetype to describe a specimen that is to be collected, or to describe a specimen that accompanies a laboratory service request.
- Within an ACTION archetype to describe specimen collection, or for testing within a laboratory setting.
- Within an OBSERVATION archetype to describe a specimen being reported on.
The level of detail in this archetype will likely be in excess of current data collection in most laboratories. It's intended to be usable in both cases where there isn't a lot of detail required, and in cases where minute detail about the preparation and subdivision of specimens is required.
If the specimen is acquired from a source other than the 'Subject of care' in the health record (such as individual, an animal or environmental sample), the OBSERVATION.laboratory_test_result should clearly indicate the source 'Subject of data'.
The exact semantics of several elements of this archetype may change based on the context provided by the container archetype. For example the 'Collection method' element in the context of an INSTRUCTION archetype is the requested collection method, while the same element in the context of an ACTION archetype in the 'completed' state is the actual collection method.
This archetype is intended to be supplemented by other CLUSTER archetypes for concepts such as Specimen container, Specimen preparation, and Specimen transport details.
This archetype can be used together with the Specimen container archetype in two main ways: 'Specimen container' nested within 'Specimen' (for example when a venous blood specimen is divided between two vials, or a whole large intestine is divided into three buckets), or 'Specimen' nested within 'Specimen container' (for example when a bucket of formalin contains a section of large intestine and a rectum, or a jar contains five individually marked moles).
Please note: The term 'collection' used in this archetype always refers to the activity of obtaining a specimen from an individual. It is not intended to represent the transport of the specimen from the individual to the testing laboratory.
Laboratory Technical Framework, Volume 3: Content, Revision 3.0 [Internet]. USA: IHE International; 2011 May 19; [cited 2011 Jul 11]. Available from: http://www.ihe.net/Technical_Framework/index.cfm#laboratory
Organisation: freshEHR Clinical Informatics
Email: ian.mcnicoll@oceaninformatics.com
Date originally authored: 2009-01-27
Organisation: freshEHR Clinical Informatics
Email: ian.mcnicoll@oceaninformatics.com
Date originally authored: 2009-01-27
- Licence: This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/.
- Custodian Organisation: openEHR Foundation
- References: Hl7 FHIR Specimen resource: HL7 FHIR; Available from http://www.hl7.org/implement/standards/fhir/specimen.html Laboratory Technical Framework, Volume 3: Content, Revision 3.0 [Internet]. USA: IHE International; 2011 May 19; [cited 2011 Jul 11]. Available from: http://www.ihe.net/Technical_Framework/index.cfm#laboratory
- Original Namespace: org.openehr
- Original Publisher: openEHR Foundation
- Custodian Namespace: org.openehr
- MD5-CAM-1.0.1: 6F9CC8618B96F88D5CFD53540F30E5E2
- Build Uid: 8ffd1c21-a101-485e-9787-3db756351c1d
- Revision: 0.0.1-alpha
For example: Venous blood, bacterial culture, cytology, or prostatic biopsy. Coding of the specimen type with a terminology is preferred, where possible.
Optional[{fhir_mapping=Specimen.type}]
Sometimes called the Accession Identifier. Specimen containers, for example vacuum vials or tissue cassettes, have their own identitiers which may be recorded in the 'Container identifier' element in the 'Specimen container' archetype.
Optional[{fhir_mapping=Specimen.accessionIdentifier}]
Optional[{fhir_mapping=Specimen.identifier}]
Optional[{fhir_mapping=Specimen.receivedTime}]
For example: 'fasting'; 'full bladder'; 'sterile field'; or special instructions on the handling or immediate processing of the sample, such as 'centrifuge on receipt'. This data element also be used to document any known deviations from collection or handling instructions, for example that the patient had not fasted, even when this had been originally requested. Coding of the 'Sampling context' with a terminology is preferred, where possible. If this archetype is used within an INSTRUCTION archetype, the context will reflect the intended or desired conditions at sample collection. If this archetype is used for representing an ACTION archetype pathway step which correlates with the collection being performed or completed, the context will be reflecting the conditions that existed at sample collection and this may also be copied to the 'Confounding factors' element of the OBSERVATION.laboratory_test_result archetype.
For example: Volume, mass, circumference, colour, smell, turbidity. This element can be used to specify the properties of the specimen to be collected, in the context of an INSTRUCTION archetype, or the properties of the specimen which was collected, in the context of an ACTION or OBSERVATION archetype. For example, an INSTRUCTION may request the collection of 20 ml of blood, while the corresponding ACTION records that only 15 ml was collected.
Optional[{fhir_mapping=Specimen.collection.quantity}]
Include:
openEHR-EHR-CLUSTER.physical_
openEHR-EHR-CLUSTER.physical_
openEHR-EHR-CLUSTER.body_
openEHR-EHR-CLUSTER.body_
For example: venepuncture, biopsy, resection. Coding of the collection method with a terminology is preferred, where possible. If the collection method is included in the 'Specimen type' via precoordinated codes, this data element becomes redundant.
Optional[{fhir_mapping=Specimen.collection.method}]
Coding of the name of the source site with a terminology is preferred, where possible. Use this data element to record precoordinated source sites. If the requirements for recording the source site are determined at run-time by the application or require more complex modelling such as relative locations then use the 'Structured source site' SLOT in this archetype. If the source site is included in the 'Specimen type' via precoordinated codes, this data element becomes redundant.
Utilise the more detailed archetypes to describe structured or more complex anatomical sites, or to support recording the source site at run-time by the application. If the body site has been fully identified in the 'Source site' data element, this SLOT becomes redundant.
Optional[{fhir_mapping=Specimen.collection.sourceSite}]
Include:
openEHR-EHR-CLUSTER.anatomical_
openEHR-EHR-CLUSTER.anatomical_
openEHR-EHR-CLUSTER.anatomical_
This datetime will be captured primarily in the INSTRUCTION timing, ACTION time or OBSERVATION times. However, as this is a critical piece of information, it can be useful to also associate it directly with the specimen itself.
Choice of:
Date/Time
Interval of Date/Time
For example: 'Hepatitis B'; "nerve agent'. Coding of the 'Hazard warning' with a terminology is preferred, where possible.
For example: laboratory outpatient clinic, at home, or hospital ward. This specifies the type of specimen collection location within the healthcare environment. It enables the laboratory to ask questions about the collection of the specimen, if required. The specimen collection setting may provide additional information relevant to the analysis of the result.
This element is intended to be used where the specimen has already been collected and the actual collector is known.
Optional[{fhir_mapping=Specimen.collection.collector}]
Optional[{fhir_mapping=Specimen.collection.collector}]
Include:
All not explicitly excluded archetypes
For example details about needle biopsies in prostate cancer, where both the request and reporting about the specimen are detailed and specific.
Include:
All not explicitly excluded archetypes
For example: Number of buckets, jars, vials, tubes, blocks, slides or grids.
min: >=0
Include:
openEHR-EHR-CLUSTER.specimen_
openEHR-EHR-CLUSTER.specimen_
For example: Staining or fixation.
Include:
openEHR-EHR-CLUSTER.specimen_
openEHR-EHR-CLUSTER.specimen_
Include:
openEHR-EHR-CLUSTER.specimen_
openEHR-EHR-CLUSTER.specimen_
For example the scanned image of a histopathology slide.
Include:
openEHR-EHR-CLUSTER.multimedia.v1 and specialisations or
openEHR-EHR-CLUSTER.multimedia.v0 and specialisations
For example: A specific histology slide specimen would have a specific paraffin wax block as its parent specimen.
Coding of the specimen quality issues with a terminology is preferred, where possible.
Choice of:
Coded Text- Haemolysed [The specimen was haemolysed.]
- Lipaemic [The specimen was lipaemic.]
- Icteric [The specimen was icteric.]
- Clotted [The specimen was clotted.]
- Incorrect additive [An incorrect additive such as a transport medium or preservative was added to the specimen.]
- Insufficient amount [The available amount of specimen was insufficient to undertake the examination.]
- Handling error [An error arose when handling the specimen. For example: Incorrect storage, broken container.]
- Incorrectly labelled [The specimen was labelled incorrectly.]
- Age [The specimen was too old to analyse or to analyse accurately.]
- Technical failure [The specimen could not be analysed for technical reasons.]
Text
This element is intended to be used to record a judgement about whether or not the specimen quality was good enough for testing, and whether or not testing has been carried out. Coding of the specimen quality issues with a terminology is preferred, where possible.
Choice of:
- Coded Text
- Satisfactory [The specimen is of sufficient quality to allow reporting.]
- Unsatisfactory - analysed [The specimen is unsatisfactory but has been analysed.]
- Unsatisfactory - not analysed [The specimen is unsatisfactory and has not been analysed.]
- Text
Optional[{fhir_mapping=Specimen.note}]
Erling Are Hole, Helse Bergen, Norway
Vebjørn Arntzen, Oslo University Hospital, Norway (openEHR Editor)
Koray Atalag, University of Auckland, New Zealand
Heidi Aursand, Oslo universitetssykehus, Norway
Silje Ljosland Bakke, Helse Vest IKT AS, Norway (openEHR Editor)
SB Bhattacharyya, Sudisa Consultancy Services, India
Greg Burch, Tiny Medical Apps, United Kingdom
Ady Angelica Castro Acosta, CIBERES-Hospital 12 de Octubre, Spain
Peter Fedorcsak, Oslo universitetssykehus, Norway
Shahla Foozonkhah, Iran ministry of health and education, Iran
Francesca Frexia, CRS4 - Center for advanced studies, research and development in Sardinia, Italy
Heather Grain, Llewelyn Grain Informatics, Australia
Åshild Halvorsen, Helse Nord RHF, Norway
Sam Heard, Ocean Informatics, Australia
Evelyn Hovenga, EJSH Consulting, Australia
Lars Ivar Mehlum, Nasjonal IKT HF, Norway
Christina Jaeger-Schmidt, Heidelberg University Hospital, Germany
Lars Morgan Karlsen, DIPS ASA, Norway
Nils Kolstrup, Skansen Legekontor og Nasjonalt Senter for samhandling og telemedisin, Norway
Ronald Krawec, Alberta Health Services, Canada
Tomi Laptoš, Marand, Slovenia
Siri Laronningen, Kreftregisteret, Norway
Liv Laugen, Oslo universitetssykehus, Norway
Sabine Leh, Helse Bergen, Norway
Heather Leslie, Atomica Informatics, Australia (openEHR Editor)
Jens Lien, Bouvet Norge AS, Norway
Neranga Liyanaarachchi, Ministry of Health, Postgraduate Institute of Medicine, Sri Lanka
Anne M Gromsrud, DIPS AS, Norway
Gunn Marit Barstad, Stavanger Universitetssykehus HF, Norway
Ole Martin Sand, DIPS ASA, Norway
Shane McKee, Belfast Health & Social Care Trust, United Kingdom
Ian McNicoll, freshEHR Clinical Informatics, United Kingdom (openEHR Editor)
John Meredith, NHS Wales Informatics Service, United Kingdom
Pourya Nasimi, Trita Health-tech Company, Iran
Arunakiry Natarajan, management4health, Germany
Bjørn Næss, DIPS ASA, Norway
Andrej Orel, Marand d.o.o., Slovenia
Jayashree Panickar, Karolinska Institute, Sweden
Ana Pereira, CINTESIS, CUF-Porto, Portugal
Nils Petter Tveranger, Helse Vest IKT, Norway
Jussara Rotzsch, Hospital Alemão Oswaldo Cruz, Brazil
Ingrid Skard, Edproof, Norway
Lídia Sousa, CINTESIS; Faculty of Medicine of Oporto University, Portugal
Natalia Strauch, Medizinische Hochschule Hannover, Germany
German Review Summary, HiGHmed Germany, Germany
Norwegian Review Summary, Nasjonal IKT HF, Norway
Rowan Thomas, St. Vincent's Hospital Melbourne, Australia
Anders Thurin, VGR, Sweden
John Tore Valand, Helse Bergen, Norway (openEHR Editor)
Ørjan Vermeer, Haukeland Universitetssjukehus, Kvinneklinikken, Norway
Lin Zhang, Taikang Insurance Group, China
Enagnon ZOUNCTHEME, Aix Marseille Univerity, Benin
- German: Anneka Sargeant, Medizinische Informatik, UMG, anneka.sargeant@med.uni-goettingen.de
- Norwegian Bokmal: Kristian Berg, Gro-Hilde Ulriksen, Line Silsand, Universitetssykehuset Nord-Norge, kristian.berg@unn.no, gro-hilde.ulriksen@unn.no, line.silsand@unn.no, *
- Portuguese (Brazil): Adriana Kitajima, Débora Farage, Fernanda Maia, Laíse Figueiredo, Marivan Abrahão, Core Consulting, contato@coreconsulting.com.br, Hospital Alemão Oswaldo Cruz (HAOC)
- Arabic (Syria): Mona Saleh