Transaction: Diagnostic imaging request

STATUS:

Announced

OWNER:

Imaging workgroup

STANDARD:

HL7 FHIR

VERSION:

N/A

DATE:

2019-12-04

DEFINITION:

This is an announced draft to initiate a new message definition for diagnostic imaging requests.

• Please note the owning group of this is in the process of being defined (cfr. infra)
• Attention: The text infra is the  literal  initial signal of intent and as the status of this transaction is 'announced', this is subject to change.
• Following a more detailed description in FHIR R4, this transaction was reworked it will however still change pending input from RIZIV-INAMI and various stakeholders.

The owner(s) of the project and contact details

• University Hospitals Leuven (UZ Leuven)
  Contact: Erwin Bellon, erwin.bellon@uzleuven.be
• Nexuzhealth
  Contact: Bart Van den Bosch, CTO, bart.vandenbosch@nexuzhealth.com
• Invitations to be project owner has been sent to the Belgian Society of Radiology (BSR), the Belgian Society for Nuclear Medicine (Belnuc), Domus Medica and Zorgnet-Icuro.

Why and what for is it going to be used

This project aims at standardizing electronic requests for diagnostic imaging investigations (such as radiology or nuclear medicine), including forms with patient safety information.

Short-term motivations:

• To eliminate the need for requester to manually enter information that could be automatically obtained from the local medical record, thus increasing efficiency and decreasing errors.
• To increase the amount and quality of clinical information included with the request.
• To provide a common framework for supplying essential information prior to the imaging procedure, including information related to patient safety (for example standardized questionnaires about possible contra-indications for MR imaging).
• To have more options for automated information processing at the side of the imaging service, including integration of advanced decision support tools.
• To provide common guidelines and a common procedure, independent of the individual imaging expert or institution that will perform the examination.

Proposed points of attention in designing the standard:

• The ability to start with standardization of the more common procedures and questionnaires, potentially with only minimal structure in the clinical information, but to later extend the message to include more structured information.
• Backwards compatibility, so that new structured information items can be included without breaking compatibility with legacy systems.
• A technical format for the messages that can also be used for other applications in medical cooperation (general referrals, for example). Hence, maximal reuse of international standards available from IHE and from FHIR, and in any case adherence to the concepts used in those standards.

In this standardization project, a generic message will be defined that can be used for a general imaging request with, at this point in time, only minimal structure in the medical information. For a number of imaging exams, a more extended set of structured medical information items will be defined already. This can later be extended gradually according to the needs and the capabilities of the communicating information systems.

For the short term it must be possible to use these messages over the eHealthBox. This addressed communication has its limitations, however, when it comes to workflow, flexibility in having the patient chose the service provider, and coordination between all parties involved in the care process. Therefore, the concepts and data elements used in the message(s) must already take into account a future more powerful communication infrastructure.

In such an architecture, of which the design is outside the scope of the current standardization project, requests could be picked up by any authorized service provider (potentially based on such factors as waiting times and convenience to the patient), the stages in the process could optionally be more strongly coordinated, and it would be easier for the patient and other care providers to actively participate in or follow up the process.

Target audience: who will send and who will receive this message

Senders are typically general practitioners or external specialists (physicians not working in a hospital setting). The messages must also be suited for hospital physicians who request exams from external imaging centers, probably through the hospital’s EMR.

Receivers are private radiologists or groups, radiology or nuclear medicine departments structured in a hospital, or ‘virtual’ departments that provide highly specialized imaging services such as PET/MR or PET/CT.

Eventually, the options for in-hospital electronic ordering (to the own imaging departments) will become aligned to the concepts for ordering between institutions. That will be a gradual process: at first the amount of information that can be exchanged between parties that use different EMRs is probably less than what is available for cooperation within a single EMR. But in designing the inter-institutional workflow, the future impact on intra-institutional workflow must already be taken into account.

 

The type of information

Therapeutical, including the administrative information needed for workflow.

Technical format high level structure

This draft works around the following structure in FHIR R4 resources, an example can be found on the link infra.  This all might still significantly change! The idea of this draft is to evolve in iterations. For now, it has a focus on a limited use case, thus only a 'skeleton' approach is described here.

Proposed message uses one FHIR resource ‘serviceRequest’ (https://www.hl7.org/fhir/R4/servicerequest.html )and  - for now  - uses the ‘contained’ mechanism to include all supporting information (https://hl7.org/fhir/R4/references.html#contained ) As such, this one serviceRequest can be used in different architectural approaches. This is a reason to stress the importance of the FHIR <narrative> concept.

1 ServiceRequest

+ optional elements to use as <supportingInfo> and to include as <contained> resources:

• 0..* QuestionnaireResponse resources
• 0..* Observation resources
• 0..* DocumentReference resources

Minimally provide in the ServiceRequest:

• Narrative (following FHIR rules)
• RECOMMENDED: Priority (FHIR codeset)
• Code to express what is requested (SNOMED-CT is RECOMMENDED but others or text allowed)
• Category: use SNOMED-CT  103693007 – Diagnostic procedure

Minimally provide in a QuestionnaireResponse (if given):

• Reference to questionnaire
• For each answer:
  • Reference to original question (String)
  • Answer (in one of the formats accepted by FHIR specs)
  • RECOMMENDED: the original question (String)

Data needed (besides any fields required in FHIR basic specs!)

Minimally provide in Patient:

• Follow be-patient profile

Minimally provide in a Practitioner:

• Follow be-practitioner profile

Minimally provide in an Observation (if given):

• Follow be-observation profile
• RECOMMENDED: Code in SNOMED-CT to express observation

Minimally provide in a DocumentReference (if given)

• RECOMMENDED: type of document

The transport layer

For the short term: eHealthBox. Part of the information referenced from within the message could reside in the systems of the eHealth hubs and vaults, however.

For the longer term, a new workflow and coordination infrastructure that is not limited to addressed communication.

Timing

From a study of existing standards and approaches, the message infra is already proposed. It can be used for further discussion.

For the first phase, medical work on the content and technical work on the message format can proceed in parallel. The medical work is on the critical path, however. We probably have to focus on specific use cases first.

When an initial proposal has been formulated for at least one or two use cases, this medical content could in principle be translated to the technical framework quickly. However, at this stage extensive validation by the WGSE is indicated. That work must not be rushed.

Next steps could be to reiterate over the results, or to already propose them as the results of this project, or to validate these messages first in controlled routine. The most appropriate course of action must be decided in consensus among the medical community and the participating software providers. UZ Leuven and nexuzhealth can commit to actively participating in pilots as a receiver of such messages and to integrate those into the workflow provided by the hospital EMR. It is essential, though, that the senders can generate the workflow initiating messages from within their EMR.