Share this page:

FHIR® Implementations
Dedicated to the discovery, definition and publishing of HL7® FHIR® Implementation Guides, Conformance, Profiles, Extensions and ValueSets serving the Canadian context.
Members: 174
Contact: Joel Francis
Admins: Linda Monico
Type: Open
Access: Public
Dedicated to the discovery, definition and publishing of HL7® FHIR® Implementation Guides, Conformance, Profiles, Extensions and ValueSets serving the Canadian context.

About

Welcome to the Canadian FHIR implementation community forum. The purpose of this forum is to collaborate on areas of FHIR implementation that will advance implementations across Canada, while contributing to the global adoption of FHIR. The objective is to develop pan-Canadian approaches to constraining and extending FHIR. The community has been active since January 2016 and has been growing ever since!

The community currently has three streams of activity:
1. Topical workstreams
2. Monthly community calls to share workstream progress and other FHIR-related news
3. A general forum to ask questions and share information

The table below provides more details on the workstream activity:

Workstream Co-Chairs Objective Progress to date
Smart on FHIR

Attila Farkas (Infoway)

Gavin Tong (Gevity)

  1. Investigate these emerging FHIR technologies for applicability to the Canadian market
  2. Create reference material to support and promote national adoption
  3. Identify the need and kick-off activities needed to create necessary FHIR elements that support Canadian implementations
  1. Drafted core objectives and initial action items
  2. Presented a Business Case overview for SMART on FHIR (video here)
  3. Conducted a review of architectural considerations
  4. Analyzed usable OAuth2 grant schemes for SMART applications
  5. Created a demo application shared on GitHub
  6. Start creating a marketing engagement strategy to educate, promote and invite more industry participation. Doc here.
Solution Architecture

Igor Sirkovich (OMHLTC)

Kris Lewis (Sierra Systems)

  1. Serve as a forum for all architectural questions about implemention of FHIR based solutions
  2. Discuss Canadian URI (incl. mapping to OIDs), profiles and extensions
  1. Review FHIR URI strategy
  2. Full list of provincial Patient ID URIs
  3. Partial list of provincial Org URIs
  4. Started work on provincial provider URIs
  5. Started discussion paper on IG publisher
Tooling

Attila Farkas (Infoway)

Frederic Laroche (Gevity Inc.)

Main focus of the working group is the discovery, identification, implementation and education surrounding tooling and best practices for FHIR development in Canada
  1. Identified a logical capability model that enables collaborative FHIR development, support digital integration and sharing
  2. Concluded discovery phase for the core component of the model - the FHIR Registry
  3. Launched the Canadian FHIR Registry at the September 2017 FHIR Community meeting
Client & Provider Registries

Kris Lewis (Sierra Systems)

Natalya Pogrebetsky (eHealth Ontario)

Define FHIR PR and CR use cases
  1. Ontario shared PR and CR specs with the working stream and provided business and technical overview
  2. PR/CR working group working on Canadian FHIR use cases
eReferrals

Tim Berezny (CareDove)

Caryn Harris (Orion Health)

  1. Build eReferral use cases
  2. Prototype eReferral use cases
  3. Select Resources to include in Specifications
  4. Write preliminary Specifications for broader use
  1. Overall use case flows combined into a single modular flow diagram: diagram and video.
  2. A demo video of some of eReferral workflows in action in a pilot environment: simple, SMART, advanced business logic
  3. Primary Resources have been identified. Identifying the role of the Task Resource.
  4. FHIR Resources applied in pilot environment, Specification writing still pending, outsanding: authentication mechanisms.
Business Case for FHIR

Attila Farkas (Infoway)

Shamil Nizamov (BC MoH)

Creation of reference material for those new to FHIR on the benefits of its adoption
  1. Concluded a storming phase identifying aspects relevant to a business case
  2. Collected community feedback and published a baseline of best practices.
Community Monthly Calls

Gavin Tong (Gevity Inc.)

Yaron Derman (eHealth Ontario)

  1. Share progress within the workstreams within the broader FHIR community
  2. Identify and promote FHIR education and implementation activities
  1. Informative updates and discussions about FHIR globally and progress across the workstreams
  2. Average 17 participants per call.

The FHIR community forum is a great place to learn, share and collaborate, whether you are new to FHIR or are already have deep FHIR experience.

Activity

Yaron Derman created a new discussion in FHIR® Implementations
Exciting news regarding eHealth Ontario's online Innovation Lab! As of June 29th, registered users of the Innovation Lab can explore integration with the Ontario Laboratories Information System (OLIS) using the draft Fast Healthcare Interoperability Resources (FHIR) specification. This complements the DHDR (Medication) FHIR interface that is already available in the Innovation Lab. For more information on how to use OLIS FHIR or any of our other interfaces in the Innovation Lab, please visit the Innovation Lab (https://www.innovation-lab.ca/).
Gavin Tong replied to a discussion in FHIR® Implementations
Hi Everyone, The SMART on FHIR work stream is going to take a break in August and will resume in September. In August we're going to develop the work plan that we'll review in September. If you have topics that you'd like to see on the plan please share them in the forum. The topics we have to date are: 1) Getting source system vendors (e.g. HIS, EMR, etc.) to develop SMART on FHIR APIs 2) FHIRCast Overview and Demo 3) SMART on FHIR list of Canadian projects As a reminder, if you have any great presentations related to SMART on FHIR - from executive overviews to technical deep dives - please share them here: ... Thanks, Gavin
Matt Zukowski joined a group
Logo
Dedicated to the discovery, definition and publishing of HL7® FHIR® Implementation Guides, Conformance, Profiles, Extensions and ValueSets serving the Canadian context.
Tim Berezny replied to a discussion in FHIR® Implementations
Note: My apologies, I incorrectly posted a date in June in my reminder, it is actually TODAY at 11. This is an ad-hoc extra meeting beyond the normal biweekly meeting, and will be a bit more "working meeting" where we will be making a number of decisions regarding getting resources prototype-ready.
Tim Berezny replied to a discussion in FHIR® Implementations
Hello all, A friendly reminder of Tuesday's eReferral call at 11am. Here is the agenda: We are going to make decisions regarding the Patient + Task resources to get them to prototype-ready state, listed on the ServiceRequest basecamp page: Patient: https://3.basecamp.com/3573371/buckets/7773495/documents/1124394256 Task: https://3.basecamp.com/3573371/buckets/7773495/documents/1125072124 =========================== Biweekly meeting (including today) regarding the development of an eReferral FHIR specification Tues June 26 @ 11:00am Eastern https://zoom.us/j/3673894036 teleconference #: 1 855 703 8985 Meeting ID: 369 389 4036 Chair: Tim Berezny Co-Chair: Caryn Harris ================ Essential Project Resources =================== eReferral Implementation Guide: https://simplifier.net/guide/ereferraldraftiguide/home Join Basecamp eReferral Space: https://3.basecamp.com/3573371/join/PkrwfjymKQuX Join Basecamp Service Directory Space: https://3.basecamp.com/3573371/join/FBGtoAkGv77g eReferral Video Demos: https://simplifier.net/guide/eReferraldraftiGuide/FHIRNorthDemos
Tim Berezny replied to a discussion in FHIR® Implementations
In response to: ACTION ITEM: Gavin to follow-up with Tim on how to reconcile the multiple forums the eReferral stream is involved in so we are not duplicating any work There are two Basecamp pages: - FHIR eReferral Workstream (...) - FHIR Service Directory (...) These are intended to be national in nature, which is why membership is open to join. We want to provide as much input and opportunity to participate as possible. Practically speaking, the content is heavily influenced by the eReferral work going on in Ontario. The content in these workspaces is reflective of the work done in the Ontario projects, and the Ontario projects are using the content in these workspaces actively. Project speciic work (such as deadlines, roles & responsibilities, etc...) is being managed elsewhere, but anything related to the specification and architecture itself is being handled through these basecamp workspaces as the primary venue.
Michael Savage replied to a discussion in FHIR® Implementations
Hi all! Apologies for the delay in posting, please see below for the minutes from last week's Community Call. An initial note that the end-of-month Community Calls are CANCELLED for July and August and will resume in September. Open Action Items Summary • ACTION ITEM: Michael Savage to provide concise piece on the above correspondence (see below) • ACTION ITEM: Michael Savage to post reminders of these cancellations mid-July and mid-August • ACTION ITEM: Gavin to follow-up with Tim on how to reconcile the multiple forums the eReferral stream is involved in so we are not duplicating any work Attendees: Mukesh Kashyap Attila Farkas Alan Leung Harsh Sharma Igor Sirkovich Radhika Verma Shamil Nizamov Joel Francis Gavin Tong Omar Ahmad Michael Savage Agenda and Action Items Review • Reviewed the action items which have been closed since the May Community Call FHIR Versioning • Gavin updated the community on his conversation with Lloyd McKenzie re: FHIR Versioning • ACTION ITEM: Michael Savage to provide concise piece on the above correspondence (see below) • The topic is not in the debate phase anymore. There will be version-aware mime types that can be used for version-specific content negotiation using standard HTTP mechanisms and instances will be able to declare their version via the existing Resource.meta.profile structure. Specifics will be in the updated R4 spec that goes to ballot in late August, though they will likely show up in the CI build within the next month or so Summer (July/August) Community Calls • Decision was made to hold off on Community Calls for the month of July and August • ACTION ITEM: Michael Savage to post reminders of these cancellations mid-July and mid-August eRefferal • Gavin provided the update • Still lots of discussion on eReferral & SMART on FHIR • Also growing focus on forms (i.e. web forms); potential to have a SMART on FHIR app for web forms (for eReferrals) • Need to be distinguishing this eReferral workstream from provincial eReferral projects • ACTION ITEM: Gavin to follow-up with Tim on how to reconcile the multiple forums the eReferral stream is involved in so we are not duplicating any work SMART on FHIR • Gavin provided the updates • Still focusing on communications and outreach • Meetings are now every 4 weeks rather than bi-weekly; check the events calendar for the proper dates • Considering a potential FHIR Connectathon at the next IHTSDO Conference • Workstream is now dedicated purely to SMART on FHIR; focus on specific topics such as CDS Hooks will come later FHIR Tooling • Attila provided the FHIR Tooling workstream update • Still lots of activity on the use of simplifier.net • URI Registry – online tool to take advantage of the content; Joel will be presenting this to the community in a later call • Overall good number of places to display FHIR objects Solution Architecture • Igor provided the update • Shamil has provided more URIs from the BC setting • Bigger focus will be on jurisdictional architecture (aka governance) for these URIs • Also big focus may be on how to contact different jurisdictions to learn how their patients are managed so we can assign them URIs Additional Items • Reminder that the monthly July and August Community Calls are CANCELLED; will resume in September

Events



Upcoming events:
Wed Jul 25 @12:00PM - 01:00PM
FHIR Community - monthly tcon
Fri Jul 27 @ 2:00PM - 03:00PM
FHIR Solution Architecture
Fri Aug 03 @ 2:00PM - 03:00PM
SMART on FHIR four-weekly call

Forum

OLIS HL7 FHIR Consumer Query Demo Service Now Available in eHealth Ontario's Innovation Lab 07/09/18
Exciting news regarding eHealth Ontario's online Innovation Lab! As of June 29th, registered users of the Innovation Lab can explore integration with the Ontario Laboratories Information System (OLIS) using the draft Fast Healthcare Interoperability...
SMART on FHIR - CDS Hooks workstream 07/06/18
Hi Everyone, The SMART on FHIR work stream is going to take a break in August and will resume in September. In August we're going to develop the work plan that we'll review in September. If you have topics that you'd like to see on the plan plea...
eReferral Spec Development work stream 07/04/18
Note: My apologies, I incorrectly posted a date in June in my reminder, it is actually TODAY at 11. This is an ad-hoc extra meeting beyond the normal biweekly meeting, and will be a bit more "working meeting" where we will be making a number of d...
eReferral Spec Development work stream 07/04/18
Hello all, A friendly reminder of Tuesday's eReferral call at 11am. Here is the agenda: We are going to make decisions regarding the Patient + Task resources to get them to prototype-ready state, listed on the ServiceRequest basecamp page: Pati...
FHIR Implementers' Community Call - June 27, 12-1 EST 07/04/18
In response to: ACTION ITEM: Gavin to follow-up with Tim on how to reconcile the multiple forums the eReferral stream is involved in so we are not duplicating any work There are two Basecamp pages: - FHIR eReferral Workstream (...) - FHIR Serv...
FHIR Implementers' Community Call - June 27, 12-1 EST 07/03/18
Hi all! Apologies for the delay in posting, please see below for the minutes from last week's Community Call. An initial note that the end-of-month Community Calls are CANCELLED for July and August and will resume in September. Open Action Item...
Solution Architecture work stream 06/29/18
Please note the our call today is cancelled. Sorry for the late notice. Please join our next call on Friday, July 13. I've extended the repeating event to the end of this year - please ...file to update your calendar.
Solution Architecture work stream 06/29/18
If a project has its own space on Simplifier, the extension can be added there, but it would have limited exposure. My suggestion would be to repurpose our Canadian URIs registry to "Canadian URIs and Extensions" registry (utilizing both namingSys...
Solution Architecture work stream 06/26/18
My understanding was that they should be projects under the Canadian Registry
Solution Architecture work stream 06/26/18
Well, extensions are obviously should be in Canadian registry on Simplifier, but where? Once we agreed that Simplifier is the tool by default for our registries I'm guessing that everyone has this in mind and we are not talking about other possible r...
Solution Architecture work stream 06/26/18
Hopefully people are putting extensions on Simplifier: https://simplifier.net/ui/organization/canadianfhirregistry This is a useful extension!
Solution Architecture work stream 06/26/18
Hi all, Do we have Canadian extension repository, similar to Canadian URI registry, and if not, do we need one? For example, in one of our FHIR projects, we need to define the First Nations Reserve information. I’m wondering if other provinces...
FHIR Implementers' Community Call - June 27, 12-1 EST 06/26/18
Hi all! As a companion to the relevant agenda item (2b) in the June 27th Community Call Agenda posted previously in this thread, please see below for the link to provide feedback on Ontario's Provincial Client Registry FHIR Implementation Guide (P...
eReferral Spec Development work stream 06/25/18
Hello all, A friendly reminder of Tuesday's eReferral call at 11am. Here is the agenda: We are going to make 9 decisions regarding the ServiceRequest resource, listed on the ServiceRequest basecamp page: https://3.basecamp.com/3573371/buckets/777...
Ontario Provincial Client Registry HL7 FHIR Implementation Guide In-depth review 06/21/18
Hi everybody, Ontario will be launching an HL7 FHIR query option for its provincial client registry in the near future. In case you are interested, below are details for an upcoming webinar that will provide a detailed review of the contents of t...

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.

Architecture ( 1 Document )

BusinessCase ( 6 Documents )

CDS Hooks ( 0 Document )

Client Registry ( 2 Documents )

Consent Management ( 0 Document )

eReferral ( 0 Document )

Meeting Materials ( 6 Documents )

Provider Registry ( 1 Document )

SMART on FHIR ( 3 Documents )

Tooling ( 6 Documents )

Why FHIR, Why Now?

Published on Dec 14, 2017 by Tasha Shaw-Verbic

Pourquoi utiliser FHIR et pourquoi maintenant

Published on Dec 13, 2017 by Tasha Shaw-Verbic

Video

OAuth2, OpenID and SAML2 overview

An overview of these specifications and technologies and how they relate to SMART on FHIR.

01/19/18
FHIR in Canada

Infoway Partnership Conference 2017. Presented by Yaron Derman, Manager, eHealth Standards, eHealth Ontario, and Attila Farkas, Director, FHIR Strategy and Implementation, Canada Health Infoway

01/03/18

Solutions

  • Canadian FHIR Registry
  • FHIR Terminology Service API
  • HAPI FHIR
  • HAPI v2
  • HL7 Explorer
  • InfoRMS
  • InfoScribe
  • Message Builder
  • Message ReMixer
  • Object Identifier (OID)
  • SNOMED CT Browser
  • Terminology Gateway
  • Terminology Service API
  • TermWorks
  • WebHook Notifications

The Canadian FHIR® Registry supports collaborative development in an effort to accelerate sustainable growth of FHIR, locally and internationally. The registry will be the home of national FHIR profiles recommended for use in Canada, including extensions, value sets, URIs and other useful, commonly used components. It is also host to a growing number of national, jurisdictional and locally shared FHIR projects, and is open to all Canadian implementers.

The Canadian FHIR Registry offers:

  • seamless integration of profile editing using Forge (free FHIR profile editor)
  • designated project space
  • supports project teams of up to 100 individuals
  • online authoring of implementation guides
  • integration with source control tools such as GitHub
  • version controlled environment

The Canadian FHIR Registry blends software development best practices with the requirements of modelling in FHIR, essential to delivering successful project requirements while having continuous access to structure validation, rendering and publishing.

This email address is being protected from spambots. You need JavaScript enabled to view it.

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.

In November 2017, the Canadian HL7 InfoCentral community determined that there was no longer any need to do further updates to the pan-Canadian Version 3 messages. As a result, the December 2012 releases of MR02.06.01 and CeRx 4.4.2 are the latest pan-Canadian publications of these standardized messages.

The HL7 Explorer, the Master Terminology Worksheet (MTW) and all other messaging related artifacts are aligned with the latest releases.

Overview
 

Learn about the features HL7 Explorer: search once, graphical representation, quick hints, etc.

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 and pan-Canadian Subsets. Not sure if you have access to InfoRMS? Manage your InfoRMS Access in your user profile.
SNOMED CT
 

Prior to submitting a SNOMED CT request, it is the requestor's responsibility to:

  1. Validate that the content does not exist in either the International or Canadian editions of SNOMED CT
  2. Comply with the appropriate Editorial Guidelines

Submit or follow requests to SNOMED CT

pCLOCD/LOINC
 

Prior to submitting a pCLOCD/LOINC request, it is the requestor's responsibility to:

  1. Validate that the content does not exist in LOINC or the pCLOCD
  2. Comply with Regenstrief Editorial Guidelines (note: login required)

Submit or follow requests to pCLOCD/LOINC

pan-Canadian Subsets
 

Prior to submitting a Subset request, it is the requestor's responsibility to:

  1. Validate the content against the subsets in Terminology Gateway
  2. Comply with the appropriate proper terminology Editorial Guidelines

Submit or follow requests to pan-Canadian Subsets

 

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.

Canada Health Infoway has an arrangement in place with HL7 International that allows Infoway to submit OIDs to HL7 International on behalf of Canadian Implementers free of charge. There is a $250 USD fee per OID request if done directly with HL7 International.

To submit an OID, download the registration form that corresponds to your OID request. Email the completed form to This email address is being protected from spambots. You need JavaScript enabled to view it.

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 that is provided by request (free of charge) 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.

 

knowing Learn More

  • This email address is being protected from spambots. You need JavaScript enabled to view it.
  • SNOMED CT Education
  • Apelon User Guide
  • Infoway User Installation Guide
  • How does TermWorks Work?
  • TermWorks FAQs

Automated notifications of new content in Terminology Gateway

A WebHook is an HTTP callback. When new content is published in the Terminology Gateway, a publishing event will be POSTed to each registered WebHook, notifying their respective owners about the publication.

WebHook registration

Individual users can register for WebHook notifications by sending an email to: This email address is being protected from spambots. You need JavaScript enabled to view it. and specifying the WebHook endpoint. Upon registration, a unique api_id will be assigned to the WebHook. Each notification POSTed by the Terminology Gateway will contain the api_id, allowing the endpoint to verify that the notification was indeed issued by the Terminology Gateway. The api_id must be echoed back by the WebHook endpoint in the body of the notification response.

WebHook interface

The WebHook endpoint must serve HTTP requests conforming to the following interface:

HTTP Request

{
  "api_id": "cb570e5a2748f349f9119431db836b3a23fdb6571afee34c0432d87220f2431b",
  "base_url": "https://termapi.infoway-inforoute.ca/rest/v1/",
  "notification_time": "2017110711:07:00",
  "targets": [
    {
      "id": "2.16.840.1.113883.2.20.6.1",
      "name": "Canadian Clinical Drug Data Set (CCDD)",
      "type": "package",
      "version": "20171016",
      "effective_date": "20171016",
      "publication_time": "2017103015:20:23",
      "message": "Monthly CCDD update for October 2017"
    },
    {
      "id": "2.16.840.1.113883.2.20.3.443",
      "name": "PrescribeIT",
      "type": "package",
      "version": "LPR2",
      "effective_date": "20171103",
      "publication_time": "2017110309:37:22",
      "message": "PrescriptionMedicinalCode version reflecting the October 2017 CCDD update"
    }
  ]
}
				
  • api_id: as previously mentioned, each notification POST contains the api_id granted at registration.
  • base_url: the base URL for the native REST API endpoint of the originating system. This can be used to call back the Terminology Gateway via APIs in order to programmatically download updated content.
  • notification_time: the timestamp of the WebHook notification in yyyyMMddHH:mm:ss format.
  • targets: list of updated targets. Each entry in this array corresponds to a Terminology Gateway artifact (subset, codesystem, map, package) that was updated and is therefore subject to the notification. The target list will only include artifacts for which the user has registered to receive notifications. Users can register to receive notifications about content updates using the Terminology Gateway User Interface or by invoking the native REST APIs.

    Each of the notification targets contains the following fields:
    • id: the artifact id, typically an OID
    • name: the artifact name
    • type: the artifact type: subset, codesystem, package or map
    • version: the published version id
    • effective_date: the effective date associated to the artifact version, in yyyyMMdd format
    • publication_time: the publication time in yyyyMMddHH:mm:ss format
    • message: optional message describing the published artifact version

HTTP Response

HTTP Response code: 200 for success, any other response code will be interpreted as an error
Sample HTTP Response Body:

{
  "api_id": "cb570e5a2748f349f9119431db836b3a23fdb6571afee34c0432d87220f2431b",
  "result": "success",
  "message": "Successful processing of the WebHook notification"
}
  • api_id: as previously mentioned, each notification response must echo back the api_id granted at registration.
  • result: success if the web hook notification was successful, any other value will be interpreted as an error.
  • message: optional response message.


Error handling

When receiving an error as a result of a WebHook notification, the Terminology Gateway will retry the notification four times at 15 minutes intervals. If still unsuccessful after four notification attempts, the system will drop the notification and will notify the user by email that the WebHook couldn't be invoked.

Sample code

Demo code for a sample WebHook endpoint can be found here: 

https://github.com/CanadaHealthInfoway/tgateway-webhook

Web Conference

Please login to acquire access to the InfoCentral web conferencing.

Members

Joel Francis
Canada Health Infoway
OFFLINE
Contact
Linda Monico
Canada Health Infoway
OFFLINE
Admin
Matt Zukowski
Akira / Right Health
OFFLINE
Member
Halina Labikova
Evinance
OFFLINE
Member
Greg Peres
Identos Inc.
OFFLINE
Member
Attila Farkas
Canada Health Infoway
OFFLINE
Member
Ivan Yuen
Health Quality Ontario
OFFLINE
Member
Ben Macerola
OntarioMD
OFFLINE
Member
Peter Bomberg
Health Canada
OFFLINE
Member
Saurav Bhardwaj
Future Idea Group Inc.
OFFLINE
Member
Daniel Heo
TELUS
OFFLINE
Member
A Mehta
N/A
OFFLINE
Member
Dustin Doan
CognisantMD
OFFLINE
Member
Mark VanRietschoten
QHR Technologies
OFFLINE
Member
Andrew Cummings
Regional Muncipality of York / McMaster
OFFLINE
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