Mathieu’s Story: #Digitalhealth provides the tools he needs to manage his condition and feel like he is in the driv… https://t.co/YJLVi7cFH2
Join a community of interest
Standards and specifications to electronically share health information consistently, safely and reliably
Support for digital health implementations
Resources and enablers to accelerate clinical interoperability
What's going on in clinical interoperability and digital health
What this site is about, future plans and how to reach us
LEADERS
Seema Nayani, Pharmacist Leader Infoway
KEY RESOURCES
Click Manage documents to:
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.)
Published on Aug 22, 2017 by Lisa Sever
Published on Feb 07, 2017 by Seema Nayani
Published on Dec 23, 2016 by Seema Nayani
Published on Dec 23, 2016 by Seema Nayani
Published on Feb 11, 2016 by Wendy Huang
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:
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.
All project artifacts are backed up weekly, on Sunday nights. Each snapshot will be retained for 10 days. The project owner can request an as-is snapshot containing all the necessary artifacts such as text, xml, json, md and image files by contacting This email address is being protected from spambots. You need JavaScript enabled to view it..
Organization projects can be viewed without logging in. To edit or request a new project, This email address is being protected from spambots. You need JavaScript enabled to view it. with the details.
The Canadian URI Project is a repository of identifier and code system namespaces. Capturing key metadata as FHIR® NamingSystem resources provides an automatic mapping of OIDs to URIs or vice versa.
To make the discovery of these artifacts more flexible, the Canadian URI Registry (alpha) was developed to allow artifacts to be queried via plain text, OID, URI or their respective identifiers. These identifiers are created according to the URI guidelines and posted to the FHIR Solution Architecture Workstream for approval.
It is important to note that all searchable artifacts are to be curated via the Canadian URI Project in Simplifier. There are ongoing discussions with the FHIR Solution Architecture Stream to have a single representative manage data for their respective jurisdictions.
A scheduled task is run periodically, making all new or modified artifacts searchable after a 20 minute window.
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.
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.
Open source integration tools 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 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.
HAPI for HL7 v2 messages is an open-source, object oriented HL7 v2.x parser developed for the Java platform.
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.
Prior to submitting a SNOMED CT request, it is the requestor's responsibility to:
Submit or follow requests to SNOMED CT
Prior to submitting a pCLOCD/LOINC request, it is the requestor's responsibility to:
Submit or follow requests to pCLOCD/LOINC
Prior to submitting a Subset request, it is the requestor's responsibility to:
Submit or follow requests to pan-Canadian Subsets
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.
Message Builder offers a number of key features and benefits:
Infoway Message Builder comes with built-in runtime APIs that support a number of pan-Canadian specifications:
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.
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.
Message Builder comprises two parts:
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.
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 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.
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.
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.
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:
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 is licensed under Apache License, Version 2.0. To use Message Builder, you will need
Message Builder v2.1 for .NET
Message Builder is licensed under Apache License, Version 2.0. To use Message Builder:
Message Builder is licensed under Apache License, Version 2.0. To use Message Builder:
Message Builder is licensed under Apache License, Version 2.0. To use Message Builder, you will need
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.
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. for all Non-jurisdictional and Infoway owned subsets. All other requests must be sent to Jurisdictional Representatives for OIDs following these guidelines listed:
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.
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.
Browse Terminology Gateway Now
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.
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.
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.
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.
The WebHook endpoint must serve HTTP requests conforming to the following interface:
{ "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" } ] }
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" }
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.
Demo code for a sample WebHook endpoint can be found here:
Mathieu’s Story: #Digitalhealth provides the tools he needs to manage his condition and feel like he is in the driv… https://t.co/YJLVi7cFH2
by Infoway
Improving the quality of patient care through the effective sharing of clinical information among health care organizations, clinicians and their patients.