4.16 DiagnosticReport リソース

Home ＞ Clinical ＞ DiagnosticReport [diagnosticreport]

The findings and interpretation of diagnostic tests performed on patients and/or specimens. The report includes clinical context such as requesting and provider information, and some mix of atomic results, images, textual and coded interpretation, and formatted representation of diagnostic reports.

The resource name as it appears in a RESTful URL is [root]/diagnosticreport/

A diagnostic report is used for the set of information that is typically provided by a diagnostic service when investigations are complete. The information includes a mix of atomic results, text reports, images, and codes. The mix varies depending on the nature of the diagnostic procedure, and sometimes on the nature of the outcomes for a particular investigation.

The Diagnostic Report Resource is suitable for the following kinds of Diagnostic Reports:

• Laboratory (Clinical Chemistry, Hematology, Microbiology, etc.)
• Pathology / Histopathology / related disciplines
• Imaging Investigations (x-ray, CT, MRI etc.)
• Other diagnostics - Cardiology, Gastroenterology etc.

The Diagnostic Report is not intended to support:

• Cumulative Result presentation
• Genetic Sequencing and related reports

Comments on the suitability of this resource and/or requirements analysis for that would be welcome through the community input above.

The actual atomic result data are delegated to the common Observation Resource to make it easier to reuse them in a wider context.

There is a wide variety of names associated with the various parts of a diagnostic report. Doctors request for "tests" or "results" to be done. What the diagnostic service returns is variously called the "tests" or "results" or the "report". The individual data items are called "results" or "tests" both collectively and individually. Collections of individual data items are sometimes called "batteries" or "panels", which have various implications in different contexts. The naming confusion is worsened because of the wide variety of forms that the result of a diagnostic investigation can take, as described above. Languages other than English have their own variations on this theme.

This resource uses one particular set of terms. A practitioner "requests" a set of "tests". The diagnostic service returns a "report" which contains a "narrative" - a written summary of the outcomes, and "results" - the individual pieces of atomic data. The results are assembled in a "group" which is a nested structure that can be used to define relationships between the individual data items.

Alternate definitions: Schema/Schematron, Resource Profile

• This resource includes some elements that relate to the ordering cycle (request identifiers); these are only included to the degree that it is useful for the final report to refer back to the orders. For explicit support of the ordering cycle, see the Order, OrderResponse, and DiagnosticOrder resources.
• If the diagnostic procedure was performed on the patient directly, diagnosticTime is the time it was peformed. If specimens were taken, the diagnostically relevant time can be derived from the specimen collection times, but since the specimen information is not always available, and nor is the diagnostically relevant time always exactly the specimen collection time (e.g. complex timed tests), the reports must always include a diagnosticTime element. Note that v2 messages often carry a diagnostically relevant time without carrying any specimne information.
• A report always contains a base group for individual results. As a minimum, this contains the name of the report itself. The base group can then contain a mix of results and sub-groups. The group has a code that indicates the nature of the grouping (e.g. organism isolate/sensitivity or antibody functional testing).
• There is rarely a need for more than two levels of groups. Known uses of 3 levels include the antibody code for a goup of antibody related test, or the organism code for a group of isolate/sensitivities, or a set of perinatal measurements on a single fetus.
• Applications consuming diagnostic reports must take careful note of updated reports, and ensure that withdrawn reports are appropriately handled.
• For applications providing diagnostic reports, a report shouldn't be final until all the individual data items reported with it are final or amended. If a report is withdrawn, all the results should be withdrawn by replacing every result value with the Concept "withdrawn" in the internal terminology "Special values" (url = "http://hl7.org/fhir/special-values"), and setting the conclusion (if provided) and the text narrative to some text like "This report has been withdrawn" in the appropriate language. A reason for withdrawal may be provided in the narrative.

Search Parameters for RESTful searches. The standard parameters also apply. See Searching for more information.