As in previous years, many IHE Profiles will be tested at the Connectathon 2023, and from key Healthcare Domains, with a special focus being on the International Patient Summary (IPS) and AI in Radiology Profiles. Vendors are encouraged to submit solutions for testing across as many IHE Profiles as possible, so as to maximise interoperability test opportunities.

Most of the IHE Profiles from the ITI, Radiology, PCC, Devices, PaLM and Pharmacy domains are open for testing at the IHE-Europe Connectathon. An overview of the most popular or new profiles is provided below the Webinar section of this page.

Webinar recordings and presentations:

Watch the following webinars and presentations to learn from the IHE ITI domain co-chairs what the relevant domain has to offer in terms of IHE Profiles that can be tested at the IHE-Europe Connectathon in September 2023 (login as a guest):

IHE International Patient Summary: recording / slides Michael Nusbaum / slides Steve Moore
Introduction to the IHE ITI domain: recording / slides
Introduction to the IHE Radiology domain: recording / slides
Introduction to the IHE PaLM domain: recording / slides

 

More details on the following profiles can be found below:

• AI and REST API for imaging - IHE Profiles: AIR, WIA and WIC
• IPS (FHIR, CDA)
• PIXm, PDQm, IUA, MHD
• Sharing and access to health records including images - IHE Profiles: XDM, XDS, XCA, DSUB, XDS-I, XCA-I, XCDR
• IOCM (Imaging Object Change Management)
• PAM, SWF.b, EBIW

AI and Rest API for imaging - IHE Profiles: AIR, WIA, and WIC

You have heard the term DICOMWeb but you do not know exactly how it can impact your imaging environment or for which purpose you could implement it in your product? The IHE Radiology Domain has leveraged this feature of the DICOM standard that takes advantage of the HTTP REST protocol and XML/JSON format in three different IHE Profiles:

●      Web-based Image Access (WIA) introduces how to query for series, studies, and instances, and how to retrieve them, using QIDO-RS and WADO-RS;

●      Web-based Image Capture (WIC) is dedicated to the storage of images, it uses STOW-RS;

●      AI Results (AIR) specifies how Artificial Intelligence applied to imaging analysis results can be reliably stored, retrieved, and displayed; it reuses parts of the above two profiles.

Whether you are developing a PACS, a VNA, an Image Display, or even an imaging-enabled client application running on a smartphone, those IHE Profiles could be of interest to you. 

The strength of the DICOMWeb (DICOM Webservice Part 3.18) part of the standard resides in the fact that it relies on a lightweight protocol and thus it is in full adequation with today’s way of communicating where patients and healthcare professionals spend more and more time using their smartphone on the move instead of sitting in front of their computer. From this common observation, the IHE Radiology Domain has developed those three IHE Profiles with the goal to harmonise the way implementers use the DICOMWeb standard to address the emerging need of sharing imaging using mobile devices and other non-mobile applications.

The Web-based Image Access (WIA) Profile, defines methods for image access and interactive viewing of imaging studies. WIA can be used as an access API for different image sharing infrastructures, including but not limited to XDS / XDS-I and DICOM / DICOMweb. It is very handy in the use case where a physician with a mobile device wants to get access to images via https.

The Web-based Image Capture (WIC) Profile provides a simple, lightweight, mobile-friendly mechanism to encode and send captured images, videos and evidence documents from the mobile device to the Image Manager so that these objects can be easily integrated into the rest

of the imaging workflow. It might be appropriate in the use case where a physician or a patient wants to send pictures to another practitioner.

The AI-Results (AIR) Profile addresses a new field in healthcare: artificial intelligence and the imaging analysis results it produces. This IHE Profile relies on both “native DICOM” and “DICOMWeb”; all exchanges can be performed using either protocol. For the DICOMWeb part, it reuses the storage and query/retrieve mechanisms defined in the WIA or WIC IHE Profiles, with only slight adaptations.

Your product already implements the DICOM standard and you wonder whether you can claim support for one or more of these three IHE Profiles, below is a short recap of the DICOM features in use in those Profiles:

•        WIA: QIDO-RS Query and WADO-RS Retrieve;
•       WIC: Store Instances over the Web / STOW-RS;
•       AIR:
•       DICOM C-FIND and C-STORE SOP Classes;
•       Store Instances over the Web / STOW-RS;
•       QIDO-RS Query and WADO-RS Retrieve.

Your product already supports one of those IHE Profiles or you will give it a try? Join us 25-29 September for the 2023 IHE-Europe Connectathon. You will have the unique opportunity to meet other implementers and test the interoperability of your solution against other IHE implementations. Attending an IHE Connectathon also affords the chance to share your experience with the IHE specifications and be sure to be involved in their continuous improvement process.

You will surely find bugs but you will also be able to rely on your peers to seek guidance in fixing them.

The IHE Connectathon is not only open to final, market-ready solutions and products. IHE also welcomes prototype implementations. You will have a full week to complete your work with standards experts and other implementers to guide you through the last and most crucial part.

The IHE Connectathon test cases are already available for the WIA and WIC Profiles. THey have been used by a variety of products during the past years. Test tools are in development (WIC simulator, JSON validators) and will be made available in priority to the IHE Connectathon participants as they are releaesed in the coming months.

IPS (FHIR, CDA)

Is your EHR system ready to be used for cross-border patient care? Would you like to approach a new international interoperability project with the push of FHIR burst or using the well-known CDA format? In that case the International Patient Summary (IPS) will be the right place to realise how to achieve:

●      a minimal data set for a patient summary;

●      support to Planned and Unplanned care both within and across borders;

●      a ‘ready to global use’ data set;

●      full mapping of the ISO/EN 17269 Data Elements to both FHIR and CDA documents.

The IHE IPS Profile provides additional testing options that support occupational data and an IPS Complete with no optional sections and  emphasizes the data required and the necessary conformance of the use cases for anInternational Patient Summary.

Your product already supports an IPS Profile or you will give it a try? Join us 25-29 September for the 2023 IHE-Europe Connectathon.

The IHE Connectathon test cases are already available for the IPS Profile. They were used in a variety of products in previous years.

PIXm, PDQm, IUA, MHD

Would you like to improve your mobile or lightweight browser-based applications? Would you like to go in depth about the application of FHIR standard in the real world? IHE Profiles give you the opportunity to improve some typical use case scenarios using the FHIR standard.

The IHE ITI Domain will help you within several different IHE Profiles:

●      Starting from security: the IUA Profile adds authorisation information to HTTP RESTful transactions. The IUA actors and behavior can be added to other IHE Profiles and transactions that need authorisation. The actors in the IUA Profile manage the access tokens used for authorisation of access to HTTP RESTful services based on the flows and transactions defined in the OAuth 2.1 Authorisation Framework [OAuth 2.1]. Authorisation Clients interact with the Authorisation Server to retrieve access tokens and incorporate them into HTTP RESTful transactions to authorise access to resources on the Resource Servers. You could also add RESTful ATNA Profile to cover other security aspects.

●      Before everything: identification of the patient. The Patient Demographics Query for Mobile (PDQm) Profile defines a lightweight RESTful interface to a patient demographics supplier leveraging technologies readily available to mobile applications and lightweight browser based applications. This IHE Profile leverages HTTP transport, and the JavaScript Object Notation (JSON), Simple-XML, and Representational State Transfer (REST). The payload format is defined by the HL7 FHIR standard.

●      PIXm: go ahead with patient identification management. The Patient Identifier Cross-reference for Mobile (PIXm) Profile provides RESTful transactions to create, update and delete patient records in a Patient Identifier Cross-reference Manager and to query the Patient Identifier Cross-reference Manager for a patient’s cross-domain identifiers.

●      And now: share documents. The MHD Profile is not limited to mobile devices, using the term “mobile” only as a grouping for mobile applications, mobile devices or any other systems that are resource and platform-constrained. The Mobile access to Health Documents (MHD) Profile defines one standardised interface to health document sharing for use by mobile devices so that deployment of mobile applications is more consistent and reusable. In this context, mobile devices include tablets, smart-phones, and embedded devices including home-health devices. This IHE Profile is also applicable to more capable systems where needs are simple, such as pulling the latest summary for display.

FHIR implementation is the challenge for the next few years. If you didn’t start before, or if you need to strengthen your FHIR implementations, these IHE Profiles are a good starting point.

The IHE Connectathon test cases are already available for these IHE Profiles. They have been used by a variety of products in the past.

Sharing and access to health records including images - IHE Profiles: XDM, XDS, XCA, DSUB, XDS-I, XCA-I, XCDR

The sharing of documents using the portfolio of these IHE Profiles is now well established and successfully deployed world-wide in hundreds of communities, regions, nations and in cross-border access to health records. Their flexibility to deploy various architectures is also now well established and today millions of health records are accessible leveraging their highly interoperable specifications and wide range of testing tools

Testing at an IHE Connectathon new and evolving systems that need to be integrated in these eHealth infrastructures remains a strong market demand in numerous countries, especially at a time:

●      with the Cross-Enterprise Document Interchange (XDM) Profile when point to point secure email is deployed for targeted communication between health professionals and between professionals and patients;

●      with the Document Subscription (DSUB) Profile to enhance workflows around existing XDS deployments to issue notifications of document publication to intended recipients;

●      with the Cross-Enterprise Sharing of imaging Information (XDS-I) and cross-community (XCA-I) under deployment in a large number of national, regional or cross-border (X-Health in Europe) image sharing deployments (8 European countries and the USA), it is time to test at the IHE Connectathon product’s usability and interoperability enhancements for PACS, VNA, RIS and EMR.

●      Finally, with the expanding number of Cross-Enterprise Document Sharing (XDS) communities and in some cases, their Cross-Community Access federation (XCA), and with Cross-Community Document Reliable Publication (XCDR), the interoperability robustness of product features gain is being retested at the IHE Connectathon both with the large installed base of products.  Such IHE Connectathon testing is a prerequisite to the IHE Conformity Assessment.

The IHE Connectathon test cases and test tools are already available for the XDM, XDS, XCA, DSUB, and XCDR IHE Profiles. They have been used by a variety of products during the past years.

IOCM (Imaging Object Change Management)

The IHE Imaging Object Change Management IOCM Profile allows synchronisation of downstream systems having a copy of the same images whenever a structural change to the images occurs in the system that is considered the master of these images.

Structural changes include moving images from one study to another study of the same patient or different patient because of operator error, deleting images for quality reasons or obsolescence.

The IOCM Profile makes use of the DICOM Key Object Selection SOP class to communicate the list of images to be rejected to the downstream systems and provide the rejection reason.

The support of the IOCM Profile is a MUST for PACS, VNA and workstation systems. It often occurs that after the PACS has archived images to the VNA or routed images to workstations, some structural changes are performed on the PACS. Thanks to the IOCM Profile, these changes can be communicated by the PACS (acting as a Change Requester actor) to the downstream VNA or workstation (acting as Image manager or Image display actor). Thus, the VNA or workstations can apply the changes and remain fully synchronised with the PACS at all times.

The IOCM Profile can also be utilised to implement in a modality (as change Requester), especially for modalities sending images on the fly to the PACS. It facilitates the rejection of poor quality images for example.

PAM, SWF.b, EBIW

The well-known IHE Scheduled Workflow.b (SWF.b) Profile describes order-based imaging workflows (such as found in CT, MRI or Mammography procedures). This is handled by the use of order-driven worklists.

However, medical imaging is increasingly undertaken outside the context of an ordered procedure. It is enounter-driven (e.g., during a dermatology consultaiton, the physician decides to capture pictures of a mole for future comparison.)

The IHE Encounter Based Imaging Workflow (EBIW) Profile addresses this need. The primary goal of the EBIW Profile is to ensure that images acquired in the context of a patient encounter are combined with the corresponding metadata about the patient, the encounter, and the performed imaging procedure. This facilitates managing the imaging data, linking it into the patient medical record, and accessing it later. This IHE Profile introduces these capabilities for encounter-based imaging procedures in ways that are analogous to those of order-based imaging procedures as coordinated by the SWF.b Profile. This Encounter-Based Imaging Workflow Profile specifies how to capture appropriate context, populate relevant indexing fields, link to related data, and ensure the images are accessible and incorporated into the medical record.

Typical systems that can be part of the EBIW Profile include an EMR acting as “Encounter Manager” to provide patient metadata, encounter metadata (visit…), procedure metadata (Study IUID, Accession # …) to the modality. The modality then sends the DICOM images with appropriate metadata to the PACS. The PACS can then notify the EMR acting as “Result Aggregator” of the availability of the images.

The EBIW Profile makes use of DICOM (Modality Worklist and storage services) or DICOMweb (UPS-RS and STOW-RS) and HL7 standard (ORU-R01).

The IHE Patient Administration Management (PAM) Profile can also be supported by the EMR system in the context of the EBIW Profile:

For example, the EMR “Encounter Manager” actor could group with a “Patient Demographics Consumer” actor in the (PAM) Profile to receive a feed of patient demographics for all patients in the facility. The Encounter Manager could alternatively group with a “Patient Encounter Consumer” actor in the (PAM) Profile since the Patient Encounter Management transaction also contains patient demographics.