RT @12Maloney: Great article from @dr_pvaughan in Canadian Policy magazine on #digitalhealth @Infoway https://t.co/cmxV15Yytl
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
What is the IHE Community?
The IHE Community is a place where health care professionals and the health information industry collaborate to improve the way health care technologies and systems share information.
To become a member of this community select Join Group in the Group Menu.
If you have an idea for a community, working group or project that will drive interoperability forward, let us know! Send your suggestions
LEADER
Duane Bender, P.Eng. - Director, Digital Health Applied Research
Mohawk College
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 Feb 09, 2017 by Teri Sippel Schmidt
Published on Apr 20, 2016 by Attila Farkas
Published on Jul 29, 2015 by Attila Farkas
Published on Jan 20, 2015 by Attila Farkas
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.
This email address is being protected from spambots. You need JavaScript enabled to view it.
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.
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
Supporting 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.
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.
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.
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:
RT @12Maloney: Great article from @dr_pvaughan in Canadian Policy magazine on #digitalhealth @Infoway https://t.co/cmxV15Yytl
by Infoway