Share this page:

Diagnostic Imaging
Exploring Diagnostic Imaging topics to accelerate interoperability , such as Foreign Exam Management, Remote Reading and Radiology Synoptic Reporting.
Members: 129
Contact: Ben Macerola
Type: Open
Access: Public
Exploring Diagnostic Imaging topics to accelerate interoperability , such as Foreign Exam Management, Remote Reading and Radiology Synoptic Reporting.

About

LEADERS

Jason Nagels, CIIP, PMP - HDIRS, Manager Clinical Program

David Koff, MD FRCPC, Chair of The Department of Radiololgy at MacMaster University. Chief of Diagnostic Imaging at Hamilton Health Sciences. Professor of Radiology at MacMaster University.

KEY RESOURCES


XDS AFFINITY DOMAIN IMPLEMENTATION GUIDE

XRR-WD - Cross Enterprise Remote Read Work Flow Definition - FINAL Published Edition.

Activity

Eric Savoie joined a group
Logo
Exploring Diagnostic Imaging topics to accelerate interoperability , such as Foreign Exam Management, Remote Reading and Radiology Synoptic Reporting.
Jason Nagels replied to a discussion in Diagnostic Imaging
Just a reminder the FEM Sub-Group meeting is taking place right now at 10am EST. Please join using the information below: https://infoway-inforoute.webex.com/meet/SPS21 Conference Call Info: 1-866-626-0833 Conference Code: 753 117 1082
Jason Nagels created a new discussion in Diagnostic Imaging
Hi all - Please find below today's meeting mins: ... As a separate reminder, Tuesday at 10am is our next FEM call. Thanks, J
Teri Sippel Schmidt replied to a discussion in Diagnostic Imaging
I am adding one more direct wiki link to this forums post regarding the IHE Rad Planning Committee voting procedure: ftp://ftp.ihe.net/Radiology/iherad-2018/IHE%20Radiology%20Planning%20Committee%20Profile%20Selection%20Voting%20Process_2017%20w%20Flowchart%20v3.pdf It is also copied here (unofficially!!!!) for convenience: (the formatting gets messed up, unfortunately) March 31, 2017 IHE Radiology Planning Committee Co-charis: Mike Bohl, Radiology Group, PC, SC David Koff, MD, McMaster University IHE Radiology Planning Committee Profile Selection Voting Process 1. Short List Voting a. The Planning Committee (PC) reviews and discusses each profile b. After all profiles have been reviewed and discussed, a vote is called with each eligible member voting for their top three Short List Profiles i. During the voting process each member will rank their three preferred Profiles from 3 to 1 with 3 (3 points) being their highest ranked profile, 2 (2 points) their second-ranked profile, and 1 (1 point) their third ranked profile ii. PC Members must be present during the voting call to vote c. Scores will be summed to determine the final ranked Profile order from highest to lowest d. By default, the PC will place the 6 highest ranked Profiles on the Short List and send them to the TC for review and time estimates i. The TC co-chair may inform the PC co-chair in writing that the TC is willing to review more than 6 Profiles, in which case the PC will move the requested number onto the Short List in ranked order ii. If two (or more) Profiles are tied for the final spot on the Short List all tied Profiles will be placed on the Short List and sent to the TC for review and time estimates. 2. TC Review – Maximum and Minimum Useful Effort Time Estimates a. The TC will review each Short List Profile and submit a “Maximum Useful Effort” (MaxUE) time to the PC for the Final Vote i. The MaxUE represents the time the TC committee members believe it will take to develop the full Profile as proposed b. The TC may, if it thinks it is appropriate and with agreement from the Profile author, narrow the scope of the proposed Profile and submit, in addition to the MaxUE, an alternative Minimum Useful Estimate (MinUE) i. MaxUE will be the default work estimate during the Final Voting process ii. A Profile’s MinUE would only be considered if that is the only option for developing the profile due to TC work effort limitations (i.e., the MinUE is the only option for that last accepted Final profile to come in at or below the 110% total TC work effort) c. If the Profile author chooses to submit a MinUE estimate, the Profile author and/or TC must submit a statement clearly articulating which elements/portions of the original proposal will be removed from development in order to meet the MinUE estimate i. This will allow the PC to be better informed during the final voting process as well as serve as a guide for the TC during the development process should a MinUE profile be approved 3. Final Selection Voting a. The PC reviews and discusses all Short List Profiles after the TC has assigned them estimated MaxUE/MinUE time estimates b. After all profiles have been reviewed and discussed, a vote is called with each eligible member voting for their top three Final Profiles i. During the voting process each member will rank their three preferred Profiles from 3 to 1 with 3 being their highest ranked profile, 2 their second-ranked profile, and 1 their third ranked profile ii. PC Members must be present during the voting call to vote c. Scores will summed to determine the final ranked Profile order d. The IHE Radiology Technical Committee Maintenance item will automatically move to the Final List and the percentage of effort applied for the TC. e. The highest scoring profiles will be moved to the Final Profile list one at a time until the sum of the TF Maintenance plus the newly approved Final Profile’s MaxUE estimates are >=90% and
Teri Sippel Schmidt created a new discussion in Diagnostic Imaging
Hello DI Community- The purpose of this post is to document the non-priors use cases which are to be excluded from the Aug 2017 submission for Foreign Exam Management IHE new profile proposal. The plan/consensus from the 5/19/2017 call is that FEM Priors in XDS environment and FEM Priors in DICOM environment (aka Use Cases 1 and 2) will be put forth as the 2017 FEM profile proposal. Next January or so, this group will reconsider the other 3 use cases (remote read, ED Transfer, and Remote Consult esp oncology) to be proposed either as a Named Option to FEM or as a new profile proposal. Additional Documentation on Use Cases 3-5 here for the sake of persistence: X.4.2.3 Use Case 3: Imaging and Reporting performed in separate facilities ... Pseudocode for Use Case 3 WebSequence Diagram: title FEM Use Case 3: Imaging and Reporting in separate facilities participant DSS/OF participant Modality participant Image Manager participant Static Rules participant Foreign Exam Manager participant PIX Mgr participant Remote Image Manager participant Remote Report Manager participant 3rd Remote IM participant 3rd Remote RM participant 3rd Remote IM participant 3rd Remote RM DSS/OF->Image Manager: Procedure Scheduled activate DSS/OF DSS/OF->Reading Worklist Manager: Procedure Scheduled DSS/OF->Foreign Exam Manager: Procedure Scheduled Modality->DSS/OF: DICOM Modalityn Worklist deactivate DSS/OF Modality->Modality: new imaging study Modality->Image Manager: Send new studyn Send Images Reading Worklist Manager->Reading Worklist Manager: Business logic determinesn remote reporting required Reading Worklist Manager->Foreign Exam Manager: Create FEM-specific Ordern (HL7 v2 ORM) activate Foreign Exam Manager Foreign Exam Manager->Image Manager: DICOM Query for new study imagesn (get study to be read) Foreign Exam Manager->Foreign Exam Manager: DICOM tag morph new studyn to local values Foreign Exam Manager->Remote Image Manager: Send new study- tag morphedn Send Images deactivate Foreign Exam Manager Foreign Exam Manager->Foreign Exam Manager: determine if patient has been seen elsewhere activate Foreign Exam Manager Foreign Exam Manager->PIX Mgr: PIX Query Foreign Exam Manager->3rd Remote IM: DICOM Query Foreign Exam Manager->Foreign Exam Manager: determine relevance of priors, if applicablen DICOM tag morph to local values 3rd Remote RM-> Foreign Exam Manager: Store (Prior) Reports over time (ORU, CDA) Foreign Exam Manager->Foreign Exam Manager: HL7 tag morphn to local values Foreign Exam Manager->Foreign Exam Manager: convert report format,n if necessaryn (e.g., HL7 v2 ORU/CDA to DICOM SC) Foreign Exam Manager->Remote Image Manager: Store (Prior) Images n (include report as SC, if configured) Foreign Exam Manager->Remote Report Manager: Store (Prior) Reports over time (ORU, CDA) deactivate Foreign Exam Manager note over Foreign Exam Manager, Remote Report Manager: time passes Remote Image Manager->Remote Image Manager: purge prior images, but not study just read?? Remote Report Manager->Remote Report Manager: purge prior reports, but not newly created report Use Case 4: X.4.2.4.1 Emergency patient transfer - Use Case Description From Cezary’s email: To your question: the use case I was talking about had to with patient transfers, usually in the context of an emergency. For example, a trauma patient is brought to Hospital A; after 20 minutes during which an imaging study has been acquired and viewed by the emergency physician, the patient is moved to Hospital B which is better suited to deal with this emergency. Before the study has been officially reported by the radiologist in Hospital A (may not happen until next day), a decision is made to transfer the emergency patient to Hospital B. While the patient is in the ambulance on their way to Hospital B, the acquired imaging study - which is not technically a prior as it has not even been read by the radiologist -- is sent to Hospital B. As you can see from the example above, we are not really fetching priors here but rather currents (from Hospital A to Hospital B), so calling it "fetching priors" would be a misnomer. Note that this is different from the remote read use case too as the intent is not to read the study in Hospital B (it was acquired and will be eventually read by Hospital A, which will also bill for it). From David Koff: Neonatal example of transfer/implications Took xray of line KW- could not open CD; could not access DIR Line not in correct place Severity of not being able to access xray ... Pseudocode for Use Case 4 WebSequence Diagram: title FEM Use Case 4: ED Transfer to Tertiary Facility (DICOM and HL7 v2) participant DSS/OF participant Modality participant Image Manager participant Report Manager participant Foreign Exam Manager participant PIX Mgr participant Remote Image Manager participant Remote Report Manager DSS/OF->Image Manager: Patient Transfer A02/A12 activate DSS/OF DSS/OF->Report Manager: Patient Transfer A02/A12 DSS/OF->Foreign Exam Manager: Patient Transfer A02/A12 deactivate DSS/OF Report Manager->Foreign Exam Manager: All reports are sent to FEM Mgr for storagen Foreign Exam Manager->PIX Mgr: PIX Query n (what if the patient is notn registered at the tertiary site?) activate Foreign Exam Manager Foreign Exam Manager->Image Manager: Query for Images (DICOM) Foreign Exam Manager->Foreign Exam Manager: determine current study (and priors?),n using internal business logic Foreign Exam Manager->Image Manager: Retrieve Images n (relevant prior studies) Foreign Exam Manager->Foreign Exam Manager: HL7 and DICOM tag morphn to local values Foreign Exam Manager->Foreign Exam Manager: convert report format, if necessaryn (e.g., HL7 v2 ORU/CDA to DICOM SC/SR) Foreign Exam Manager->Remote Report Manager: Procedure Scheduled n (prep for prior report) Foreign Exam Manager->Remote Report Manager: Store Report n (if HL7 ORU text or CDA) Foreign Exam Manager->Remote Image Manager: Procedure Scheduled n (prep for NEW study (and priors?)) Foreign Exam Manager->Remote Image Manager: Store Images n (include report as SC/SR, if configured) deactivate Foreign Exam Manager note over Image Manager, Report Manager: what if the study is interpreted later? send report? note over Image Manager, Report Manager: time passes Remote Image Manager->Remote Image Manager: purge?? prior study images Remote Report Manager->Remote Report Manager: purge?? prior study reports X.4.2.5 Use Case 5: Remote Consult (report may or may not exist) -network in existence. -must include priors, esp for oncology (Use Case 5 not developed beyond this...)

Events



Upcoming events:
No events

Forum

FEM Sub-Group Meetings - Starting April 25 10am-11am EST (bi-weekly) 05/23/17
Just a reminder the FEM Sub-Group meeting is taking place right now at 10am EST. Please join using the information below: https://infoway-inforoute.webex.com/meet/SPS21 Conference Call Info: 1-866-626-0833 Conference Code: 753 117 1082
DI Community Meeting Mins - Friday May 19th 05/19/17
Hi all - Please find below today's meeting mins: ... As a separate reminder, Tuesday at 10am is our next FEM call. Thanks, J
Direct links within IHE wiki - Planning Comm voting status and Planning Comm schedule 05/19/17
I am adding one more direct wiki link to this forums post regarding the IHE Rad Planning Committee voting procedure: ftp://ftp.ihe.net/Radiology/iherad-2018/IHE%20Radiology%20Planning%20Committee%20Profile%20Selection%20Voting%20Process_2017%20w%2...
Recording additional Use Cases for FEM - deferred for now 05/19/17
Hello DI Community- The purpose of this post is to document the non-priors use cases which are to be excluded from the Aug 2017 submission for Foreign Exam Management IHE new profile proposal. The plan/consensus from the 5/19/2017 call is that F...
DI Working Group Agenda: May 19,12pm-1pm EST 05/18/17
Hi All - Please find the Agenda for tomorrow's call: ...
DI Community Meeting Mins: Friday May 5, 12pm-1pm EST 05/09/17
Hi Teri - Sincere apologies. I don't know how I could have left you off the list of attendees. I have updated it now. ... This might be a good time to mention if anyone wants to take on the role of scribe, we would be happy to have the help...
DI Community Meeting Mins: Friday May 5, 12pm-1pm EST 05/09/17
Hi Jason, Thanks for the notes. All looks good, but please add me to list of attendees, although I am noted in the content of the meeting. :) Thanks, Teri
DI Community Meeting Mins: Friday May 5, 12pm-1pm EST 05/09/17
Hi All - Please find the Meeting Mins for May 5th's call: ... Thanks, J
Focus of Scope for 2017-2018 Foreign Exam Management (FEM) IHE Proposal 05/05/17
Hello CHI Diagnostic Imaging Community, One of the discussions on the call today was about ensuring that FEM gets accepted (prioritized) as a profile for the 2017-2018 IHE cycle, as it narrowly missed the IHE Planning Committee voting approval las...
May 5/2017 - DI Community Agenda 05/03/17
Hi all - Please find the Agenda for this week's DI Community meeting below: ... Thanks, J
April 21 2017 - Meeting Mins 05/03/17
Meeting Mins for last April 21 DI Community Meeting are below: ...
FEM Sub-Group Meetings - Starting April 25 10am-11am EST (bi-weekly) 05/03/17
Apologies, but I need to cancel the FEM technical call for Tuesday, May 9th, as it conflicts with the IHE Radiology Tech Comm F2F meeting. We will reconvene the FEM tech call again on Tuesday, May 23rd. We will, however, be discussing FEM on th...
FEM Sub-Group Meetings - Starting April 25 10am-11am EST (bi-weekly) 04/24/17
Just a reminder that tomorrow (April 25) at 10am EST is the first FEM Bi-Weekly Call. https://infoway-inforoute.webex.com/meet/SPS21 Conference Call Info: 1-866-626-0833 Conference Code: 753 117 1082 See you there! Thanks,
FEM Sub-Group Meetings - Starting April 25 10am-11am EST (bi-weekly) 04/21/17
Hi All - As brought up on today's call, here are the dates for the FEM sub-group meetings. All meetings will take place 10am-11am EST. April 25, May 9, May 23, June 6, June 20 https://infoway-inforoute.webex.com/meet/SPS21 Password: Infow...
IHE Radiology Face-to-Face meeting in May 04/21/17
Hi All, The upcoming Radiology Face-to-Face meeting will be on May 9 - 12. The draft agenda is available at http://wiki.ihe.net/index.php/Rad_Tech_Agenda_2017-05-09_to_2017-05-12 Thanks, Kinson

Tasks


Tasks


Time Tracking


Gantt

Documents

Click Manage documents to:

  • view the complete list of documents or documents grouped by folder
  • upload a new document

Note: Group members are not currently notified when new documents are added. To notify others, you must post the URL to the new document in the forum. (Notification of document uploads is a feature in development.)

Manage documents You may need to login and/or be a member of the group to access this content.

DICOM ( 0 Document )

IHE ( 5 Documents )

DI Working Group Mins: May 19th,12pm-1pm EST

Published on May 19, 2017 by Jason Nagels

IHE FEM Use Case 4 - ED Transfer

Published on May 19, 2017 by Teri Sippel Schmidt

IHE FEM Use Case 3 - Study Read at different facility

Published on May 19, 2017 by Teri Sippel Schmidt

DI Working Group Agenda: May 18,12pm-1pm EST

Published on May 18, 2017 by Jason Nagels

DI Community Meeting Mins: Friday May 5, 12pm-1pm EST

Published on May 09, 2017 by Jason Nagels

May 5/2017 - DI Community Agenda

Published on May 03, 2017 by Jason Nagels

April 21/2017 Meeting Mins

Published on May 03, 2017 by Jason Nagels

April 21 Meeting Agenda

Published on Apr 20, 2017 by Jason Nagels

April 3-17 Meeting Mins

Published on Apr 11, 2017 by Jason Nagels

April 7-2017 Meeting Mins

Published on Apr 11, 2017 by Jason Nagels

April 7 Meeting Agenda

Published on Apr 06, 2017 by Jason Nagels

March 24 Meeting Mins

Published on Mar 31, 2017 by Jason Nagels

April 3rd Face to Face Agenda

Published on Mar 30, 2017 by Jason Nagels

DI Working Group Agenda: Wed March 24,12pm-1pm EST

Published on Mar 22, 2017 by Jason Nagels

March 10 Meeting Mins

Published on Mar 15, 2017 by Jason Nagels

March 10 Meeting Agenda

Published on Mar 08, 2017 by Jason Nagels

DI Community Proposal Template

Published on Feb 27, 2017 by Jason Nagels

Feb 24 Meeting Minutes

Published on Feb 25, 2017 by Jason Nagels

DI Working Group Agenda: Wed Feb 24,12pm-1pm EST

Published on Feb 23, 2017 by Jason Nagels

Feb 8 Face to Face Meeting Minutes

Published on Feb 12, 2017 by Jason Nagels

IHE Rad Non-Urgent Critical Findings Follow-up Overview

Published on Feb 09, 2017 by Teri Sippel Schmidt

DI Working Group Agenda: F2F Wed Feb 8, 9am-12pm EST

Published on Feb 06, 2017 by Jason Nagels

DI Working Group Community Minutes: January 13, 2017

Published on Jan 13, 2017 by Jason Nagels

DI Working Group Agenda: Friday January 13, 12pm EST

Published on Jan 10, 2017 by Jason Nagels

DI Working Group Agenda: Friday November 18, 12pm EST

Published on Nov 16, 2016 by Laura Repchik

Remote Read Status - Presented by C. Lindop October 21, 2016

Published on Oct 26, 2016 by Laura Repchik

DI Working Group Community Minutes: October 21, 2016

Published on Oct 26, 2016 by Laura Repchik

DI Working Group Agenda: October 21, 2016

Published on Oct 19, 2016 by Laura Repchik

DI Working Group Agenda: September 23, 12pm EST

Published on Sep 22, 2016 by Laura Repchik

Clinical Division Support and the 2017 CMS Imaging Mandate

Published on Jun 10, 2016 by Laura Repchik

DI CS eHealth Update Presentation for DI WGC May 31 2016

Published on Jun 06, 2016 by Laura Repchik

DI Working Group Agenda: May 31, 2016

Published on May 30, 2016 by Laura Repchik

Diagnostic Imaging Community - Agenda for Friday May 6, 2016

Published on May 04, 2016 by Laura Repchik

Diagnostic Imaging Community - Agenda for Friday April 8, 2016

Published on Apr 07, 2016 by Laura Repchik

Remote Read Status - Next Steps

Published on Feb 16, 2016 by Ben Macerola

Meeting Agenda: DI Working Group Friday February 12, 2016

Published on Feb 11, 2016 by Laura Repchik

IHE Suppl XRR-WD Document

Published on Jan 15, 2016 by Laura Repchik

Remote Reporting for Imaging Dec 18, 2015 Meeting Agenda

Published on Dec 18, 2015 by Laura Repchik

Clinical Requirements Remote Read Radiologists Review v2

Published on Oct 09, 2015 by Diane Larwood

Detailed IHE Remote Read Proposal

Published on Sep 11, 2015 by Ben Macerola

DI RRI 2015 07 013

Published on Jul 13, 2015 by Chris Lindop

Remote Reading iGuide - KH

Published on Jul 05, 2015 by Kinson Ho

DI RRI 2015 05 08 revPeterP

Published on May 12, 2015 by Peter Popowycz

Diagnostic Imaging WG Meeting May 8, 2015

Published on May 07, 2015 by Laura Repchik

SCWG 10 Transition to DI Community

Published on Mar 26, 2015 by Diane Larwood

Video

This Group has no videos.

Solutions

  • FHIR Terminology Service API
  • HAPI FHIR
  • HAPI v2
  • HL7 Explorer
  • InfoRMS
  • InfoScribe
  • Message Builder
  • Message ReMixer
  • Object Identifiers (OIDs)
  • SNOMED CT Browser
  • Terminology Gateway
  • Terminology Service API
  • TermWorks

FHIR web services used to access terminology data

FHIR Terminology Service APIs enable automated exchange of clinical terminology content and resources. It allows developers to easily implement healthcare applications that programmatically consume codes and subsets without requiring in-depth expertize in the fine details of terminology.

terminology gateway APIFHIR Terminology Service API

Open source integration tools useful for health IT integration projects

HAPI FHIR® is a simple-but-powerful library for adding FHIR messaging to applications. It is pure Java compatible and licensed under the business-friendly Apache Software License, version 2.0.

HAPI FHIR

 

External Solutions for API integration

Open source integration tools useful for health IT integration projects.

HAPI v2
 

HAPI for HL7 v2 messages is an open-source, object oriented HL7 v2.x parser developed for the Java platform

HAPI FHIR
 

HAPI FHIR is a simple-but-powerful library for adding FHIR messaging to your application. It is pure Java compatible and licensed under the business-friendly Apache Software License, version 2.0.

-->

Open source integration tool useful for health IT integration projects

HAPI for HL7 v2 messages is an open-source, object oriented HL7 v2.x parser developed for the Java platform.

HAPI v2

Enhanced browsing of HL7 v3

Infoway HL7 Explorer is a powerful browser for HL7 v3 structures, vocabulary and references. Used in conjunction with the pan-Canadian releases, HL7 Explorer makes locating details and information more efficient.

Overview
 

Learn about what HL7 Explorer can do for you with this brief online presentation.

MR 02.06
 

HL7 Explorer applied to the MR 02.06 HL7 v3 maintenance release

CeRx 4.4.2
 

HL7 Explorer applied to the CeRx 4.4.2 HL7 v3 maintenance release

 

 

Standards versions available for viewing in HL7 Explorer

Standard URL 
CA MR 02.06 https://infocentral.infoway-inforoute.ca/extra/ca/mr0206-html/html/search.html
CA MR 02.05.01 https://infocentral.infoway-inforoute.ca/extra/ca/mr020501-html/html/start.html
CA MR 02.05 https://infocentral.infoway-inforoute.ca/extra/ca/mr0205-html/html/start.html
CA MR 02.04.03 https://infocentral.infoway-inforoute.ca/extra/ca/mr020403-html/html/start.html
CA CeRx 4.4.2 https://infocentral.infoway-inforoute.ca/extra/ca/cerx442-html/html/search.html
CA CeRx 4.4.1 https://infocentral.infoway-inforoute.ca/extra/ca/cerx441-html/html/start.html 
CA CeRx 4.4 https://infocentral.infoway-inforoute.ca/extra/ca/cerx44-html/html/start.html
BC V02R04 https://infocentral.infoway-inforoute.ca/extra/bc/v02r04-html/html/start.html
NS CeRx 4.3 https://infocentral.infoway-inforoute.ca/extra/ns/cerx43-html/html/start.html
NS R02.04.03 https://infocentral.infoway-inforoute.ca/extra/ns/r020403-html/html/start.html
AB MR2007 https://infocentral.infoway-inforoute.ca/extra/ab/mr2007-html/html/start.html
AB R02.04.03 https://infocentral.infoway-inforoute.ca/extra/ab/r020403-html/html/start.html
AB R02.04.00 SHR https://infocentral.infoway-inforoute.ca/extra/ab/r020400-shr-html/html/start.html
AB R02.04.03 Imm https://infocentral.infoway-inforoute.ca/extra/ab/r020403-imm-html/html/start.html

Request Management Solution

InfoRMS (Infoway Request Management System) is Infoway's Request for Change Tool for SNOMED CT, pCLOCD/LOINC, pan-Canadian Subsets and pan-Canadian HL7 artifacts. Not sure if you have access to InfoRMS? Manage your InfoRMS Access in your user profile.
SNOMED CT
 

Submit or follow requests to SNOMED CT

pCLOCD/LOINC
 

Submit or follow requests to pCLOCD/LOINC

pan-Canadian Subsets
 

Submit or follow requests to pan-Canadian Subsets

HL7
 

Follow requests to pan-Canadian HL7 messaging

 

infoscribeSupporting the Standards Selection Framework, InfoScribe enables teams to collaboratively create, discuss, and publish digital health solutions from clinical requirements to specifications. Featuring templates, versioning, PDF export, inline commenting and HL7 Explorer integration, InfoScribe improves productivity and accelerates the development of healthcare solutions.

Standards Selection Framework

The Standards Selection Framework provides users with the means to plan, choose and document interoperability solutions from concept through to implementation. Starting from the Clinical Requirements identified by clinicians through to business requirements, standards and technical specifications, the framework provides a comprehensive guide through the development of interoperability solutions.

The framework also provides an opportunity for the InfoCentral community to share successful implementation projects, the standards selections made at a point in time of the project and the specifications that result from the selections made. Publishing solutions in this space will help to establish a Canadian repository of references.

clinical requirements

Clinical Requirements describe the information and workflow needs of the clinician for a specific clinical context and clinical data exchange. Using the Clinical Interoperability Principles as a guide, a set of requirements expressed in the clinician’s voice will provide the foundation for a well-designed interoperability solution.

business requirements

Business Requirements are derived from clinical requirements and provide a full picture of the solution that needs to be developed. Use cases, business rules and guidance are used to fully outline the solution design.

standards selection

Standards Selection refers to the process that has been developed to help guide teams through the selection of terminology and messaging standards. Using the line of inquiry and considerations in the forms provided implementation teams may assess the standards available and determine the best option for the point in time. The process also provides an opportunity for the InfoCentral community to share successful implementation projects, promoting standardization through reuse.

standards

Standards are an integral piece of the interoperability solution, covering both the terminology that defines the data sent, and the messaging structures that define how the data is transferred. The framework provides the access and consideration criteria to the international and Canadian standards to facilitate implementation.

specifications

Specifications provide the details for the solution to be implemented. These details include: a review of the data elements used, samples of transferred messages, the system architecture as well as the security specifications including authorization and authentication.

Solution for API integration

Infoway Message Builder allows developers to focus on the business challenges of integrating their solutions with each electronic health record implementation by abstracting the differences between different versions of pan-Canadian HL7 messaging and supporting current implementation constraints. Developers can build interfaces in a familiar development environment, using the programming language of their choice*, while the Message Builder API fosters quick and easy creation, population and access to HL7v3 requests and responses.

Infoway Message Builder v2.0 and later is enhanced to generate JAVA APIs to create, validate, marshal/unmarshal CDA documents.

 Implementation and Exchange

 

Key features and benefits

Message Builder offers a number of key features and benefits:

  1. Abstracts the complexity of HL7v3 messages and greatly simplifies the work of the developer when implementing them;
  2. Reduces the impact on developers from implementation variations;
  3. Enables companies to achieve Infoway product certification with greater confidence and reduced time;
  4. Enables developers to incorporate future message versions without re-writing their products;
  5. Can be embedded in software applications due to its open source distribution under a commercial-friendly Apache 2.0 license.

Out of the box support

Infoway Message Builder comes with built-in runtime APIs that support a number of pan-Canadian specifications:

  • MR2009 (R02.04.02)
  • MR2007 (V02R02)
  • MR 2007 (V02R01)
  • CeRx (V01R04.3)

In addition, while developers can easily build custom transport mechanisms without affecting the core, Message Builder includes native support for SOAP and RESTful message transports. Developers can configure and extend the transport as desired.

Detailed product features

  • Provides the capability to configure and populate message values that are common to all messages—this allows developers to reuse common message data, shortening the time to configure and create an interoperable system.
  • Uses simplified data types that are natural and familiar to the programming language (e.g. String for ST) rather than directly exposing the sometimes complicated HL7v3 data types—yet still allowing access to HL7v3 data types when necessary.
  • Allows developers to focus on the business-aspect of a request/response, avoiding many of the complexities of HL7v3.
  • Code-generation algorithms merge identical and similar classes together to simplify the generated API—meaning less confusion in the resulting code and an increased ability to write generic handlers for certain types.
  • Converts populated objects into HL7v3 XML requests, and converts HL7v3 responses into populated objects.
  • Provides flexibility in configuring and performing terminology-code lookups, including code set and database-backed lookups (can mix and match).
  • Associations and attributes are strongly typed, given business names when provided, and contain code docs directly from the MIFs (see wiki.hl7.org/index.php?title=MIF).
  • The algorithms inline most classes that only have a small number of properties, further simplifying the API.
  • Offers both permissive and strict modes—permissive allows many common errors and generates appropriate error comments in the XML or result object.
  • A separate validation tool is provided to test ad-hoc messages—this tool reuses the same validation components that are executed during message marshaling and unmarshalling, ensuring consistent processing of the message whether during processing or during conformance validation.

Forward looking

The power of the Message Builder architecture is in its MIF-based generation of the specification API. With Message Builder, any MIF is supported—whether a future release of the pan-Canadian specifications or a modified (constrained) jurisdiction-specific release of an existing specification. 

 

How it works

Message Builder comprises two parts:

  1. Message Builder Generator—a tool used by Infoway to take input MIFs and create Message Sets for use by Message Builder Runtime;
  2. Message Builder Runtime—an API used by developers to allow their products to support multiple Message Sets without recoding.

Message Builder Generator

Used by Infoway, Message Builder Generator takes MIFs (as the source of truth for standards specifications) and converts them into a series of Java Classes. This is done by first converting the MIFs to an XML Message Set (a simplified representation of the information present in the original MIFs), then generating Java Classes that reference standard Java data types and use business-friendly names. In the process, groups of related elements are flattened and similar message parts are placed into a single class: these steps increase ease of use and reduce the complexity of the resulting Java Classes.

MBG process

Using Message Builder Generator, Infoway is able to create multiple Message Sets, each representing the MIFs used in a single jurisdiction, but all for the same HL7v3 version.

Message Builder Runtime

Message Builder Runtime allows developers to quickly adapt to implementations in multiple Jurisdictions: incoming messages are first examined to determine the corresponding source Message Set, once identified, a series of Java Objects that represent the message are instantiated. Next, the Java Objects are turned into an HL7 message for the HL7 version corresponding to the desired destination Message Set. 

MB process

Using Message Builder Runtime developers can accept messages over the wire and on-the-fly turn them into a different HL7 message version. Given the capability of Message Builder to support future versions of HL7 messages, developers can easily future proof their products with minimal effort.

*Developer friendly

The Message Builder libraries are available for Java and Microsoft .NET. In addition, a simplified XML message format is available with REST-based services for managing mapping to/from the simplified form to the target specification XML format.

 

CDA Support

Message Builder CDA API supports the following CDA and data type specifications:

Message Builder provides  JAVA and .NET APIs for CDA document creation, validation, marshalling/unmarshalling of the following CDA document types:

  • Continuity of Care Document (CCD) (Release 1.1)
  • Consultation Notes (Release 1.1)
  • Discharge Summary (Release 1.1)
  • Imaging Integration, and DICOM Diagnostic Imaging Reports (DIR) (Release 1)
  • History and Physical (H&P) (Release 1.1)
  • Operative Note (Release 1.1)
  • Progress Note (Release 1.1)
  • Procedure Note (Release 1)
  • Unstructured Documents (Release 1.1)
  • CDA documents using pan Canadian CDA header template

Clinical applications in JAVA or .NET can use the Message Builder CDA APIs to create, validate or parse above listed types of CDA documents. Potential use cases are document source or document consumer actors in IHE XDS profile, content creator/content consumer in any content module/profile, or report creator/viewer in RIS/PACS/EMR systems.

Message Builder is available for Java and .NET

Message Builder for Java

System Requirements

  • Java 1.5 or higher
  • Maven 3.0.3 or higher (can be removed after installing Message Builder if working with a non-Maven project)

Download

Message Builder is licensed under Apache License, Version 2.0. To use Message Builder, you will need

  1. Message Builder Core and
  2. one or more Message Builder API release(s)—depending on your implementation requirements.

Select a Message Builder Version:

 

Select one or more Message Builder API releases:

 

Optional Message Builder components:

Terminology Database Resolver
Message Builder Example

Message Builder pom.xml file:

 

Message Builder for .NET

System Requirements

  • .Net Framework 3.5 or higher

Download

Message Builder v2.1 for .NET

Message Builder is licensed under Apache License, Version 2.0. To use Message Builder:

  1. Download Message Builder .NET Core 2.1.0 setup
  2. Unzip and pull out the dll files that you need:
     \ → root location of required Message Builder core assemblies (Mandatory - required all)
     \releases\ → location of Message Builder release assemblies (Mandatory - choose one or more)
  3. Copy them to your .NET project 
  4. Download Message Builder .NET 3rd-Party libraries, unzip it, and copy the files to your .NET project

Message Builder v1.5.8.1 for .NET

Message Builder is licensed under Apache License, Version 2.0. To use Message Builder:

  1. Download Message Builder .NET Core 1.5.8.1 setup
  2. Unzip and pull out the dll files that you need:
     \ → root location of required Message Builder core assemblies (Mandatory - required all)
     \releases\ → location of Message Builder release assemblies (Mandatory - choose one or more)
  3. Copy them to your .NET project 
  4. Download Message Builder .NET 3rd-Party libraries, unzip it, and copy the files to your .NET project

Message Builder v1.4.6 for .NET

Message Builder is licensed under Apache License, Version 2.0. To use Message Builder, you will need

  1. Download Message Builder .NET Core 1.4.6 setup
  2. Unzip and run SetupCore.msi file
  3. Choose a installation location <install dir>.  The setup execution should place the following directories in <install dir>:
     \lib\ → location of required Message Builder core assemblies (Mandatory - required all)
      \releases\ → location of Message Builder release assemblies (Mandatory - choose one or more)
     \src\ → location of all source code and project files required to load them into visual studios
     \debug\ → location of debug symbol files
  4. Pull out files the dll files from the \lib\ and \releases\ folders, and copy them to your .NET project 
  5. Download Message Builder .NET 3rd-Party libraries, unzip it, and copy the files to your .NET project

Localization of pan-Canadian Standards

Infoway Message ReMixer is a web-based application that allows for the localization of pan-Canadian Standards (pCS) messages to meet jurisdictional requirements, all while maintaining the integrity of the original, standard message.

msg remixerAccess Message ReMixer Now

 Implementation and Exchange

Jurisdictional ReMixes

Pan-Canadian Standards use Object Identifiers (OIDs) to distinguish between objects by assigning a numeric string that enables other systems to understand the unique information that is being shared between various systems.

  • OIDs are intended to be globally unique and never re-used
  • OIDs in the pan-Canadian standards identify terminology code systems and are transmitted in HL7 messages
  • OIDS used to identify terminology subsets are not transmitted in HL7 messages, rather these OIDs are used for vocabulary maintenance and Terminology Services
  • OIDs are used to qualify local identifiers (e.g. patient identifiers) such that the combination of an OID (assigning authority) and a local identifier remains globally unique

Browse International and Canadian Content

SNOMED International's SNOMED CT browser allows users to browse and search the SNOMED CT International Edition to explore concepts and relationships. It also provides access to browse national extensions from SNOMED International member countries including the Canadian Edition of SNOMED CT in English and French.

snomed browser Browse SNOMED CT Now

 General Documentation

Browse, download and leverage the terminology used in Canada

Terminology Gateway is a web based solution framework that enables the distribution and sharing of terminology concepts, subsets and concept maps, making them available for web browsing, download or real time query.

terminology gatewayBrowse Terminology Gateway Now

RESTful web services used to browse terminology data

Terminology Service RESTful APIs enable automated exchange of clinical terminology content and resources. It allows developers to easily implement healthcare applications that programmatically consume codes and subsets without requiring in-depth expertise in the details of terminology.

terminology gateway APITerminology Service API

Apelon’s TermWorks is an easy-to-use data mapping solution which is provided by request for free to individuals who have Standards Access. It brings powerful terminology capabilities directly to the desktop. TermWorks combines Microsoft® Excel® spreadsheet software with web services-based terminology processing to give organizations comprehensive mapping capability to SNOMED CT and the Canadian Edition of SNOMED CT.

 Education

  • Introduction to SNOMED CT (English)
  • Introduction to SNOMED CT (French)
  • This email address is being protected from spambots. You need JavaScript enabled to view it.

Web Conference

Please login to acquire access to the InfoCentral web conferencing.

Members

Ben Macerola
Canada Health Infoway
OFFLINE
Contact
Linda Monico
Canada Health Infoway
OFFLINE
Admin
Tasha Shaw-Verbic
Canada Health Infoway
ONLINE
Admin
Eric Savoie
xrad technologie / Ministère de la santé et services sociaux du Québec
OFFLINE
Member
Brent McGaw
Canada Health Infoway
OFFLINE
Member
Emilie Brisson
Ministère de la Santé et des Services sociaux
OFFLINE
Member
Babette Macrae
Accusys Solutions
OFFLINE
Member
Stephen Winnett
Carestream Health
OFFLINE
Member
Janice Spence
eHealth Ontario
OFFLINE
Member
Arif Kotadia
PHSA (Provincial Health Services Agency) British Columbia
OFFLINE
Member
Becki VanderWal
MHA and LHSC
OFFLINE
Member
Brian McGillis
Realtime Medical
OFFLINE
Member
Rob McGuffin
London Health Sciences Centre
OFFLINE
Member
Hamid Neshat
Agfa Healthcare
OFFLINE
Member
Alexander Goel
Cancer Care Ontario
ONLINE
Member

logo 1

Improving the quality of patient care through the effective sharing of clinical information among health care organizations, clinicians and their patients.



Login Register