Register |

HL7 May 2019 International Conference & Working Group Meeting, Montreal, Quebec, May 4 -10. Register more >

Share this page:

0 Share
Share
print Printemail Email
Integrating the Healthcare Enterprise (IHE)
Health care and health information professionals collaborating to improve information sharing between health care technology systems.
Members: 147
Contact: Derek Ritz
Type: Open
Access: Public
Health care and health information professionals collaborating to improve information sharing between health care technology systems.

About

What is IHE?

Unlike HL7 (or ISO, or SNOMED, or WHO, etc.), IHE is not a health informatics standards development body. Rather, IHE is a standards profiling body. IHE Profiles are implementation guides – they make standards digestible, usable, and implementable. They describe, at a conformance-testable level of detail, how a portfolio of underlying standards will be employed to address the ecosystem-wide interoperability issues associated with a specific set of healthcare use cases. IHE Profiles create re-usable, digital health building blocks by “packaging up” the 5C’s:

  • Care context
  • Content specs
  • Coding specs
  • Communications specs
  • Confidentiality and security specs

The target audience for an IHE profile is the entire care delivery network. This especially includes the jurisdictional governance entities that are tasked with operationalizing plug-and-play interoperability between disparate network participants. IHE is focused on taking digital health interoperability to scale and to mitigating the risks inherent in such an effort.

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

Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.

KEY RESOURCES

IHE Resources

Activity

Michael Nusbaum replied to a discussion in Integrating the Healthcare Enterprise (IHE)
Cheap... Flexible... Interoperable... choose 2. YIKES!!
i sure do agree with your last points, Lloyd. Leadership is everything!
Derek Ritz replied to a discussion in Integrating the Healthcare Enterprise (IHE)
Cheap... Flexible... Interoperable... choose 2. YIKES!!
Thanks, Lloyd, for the very thoughtful and thorough reply. There's a lot to think about, as we continue to progress Canada's digital health agenda. I genuinely appreciate these ideas and suggestions and clarifications. All very helpful! :)
Lloyd Mckenzie replied to a discussion in Integrating the Healthcare Enterprise (IHE)
Cheap... Flexible... Interoperable... choose 2. YIKES!!
Hi Derek, The risk in proliferation of extensions really comes from two places: 1. Systems that choose to stick their data into extensions rather than conveying it in standard elements. For example, "I use a SNOMED code for gender, so I'll send that as an extension and won't bother to populate Patient.gender" when best practice is to send both the extension *and* to map their SNOMED code to the Patient.gender value set and send that too. Or "I need to capture the patient's blood type, so I'll stick that as an extension on Patient" when best practice would be to capture blood type as a separate Observation. 2. Systems that define new extensions for concepts that already have extensions and create multiple ways of communicating the same thing. FHIR provides a few different mechanisms to help mitigate these issues: The standard is quite understandable and approachable and has lots of examples, so it's harder (though never impossible) for implementers to misinterpret the spec and decide to stick stuff in extensions rather than where it belongs Registries allow implementers and implementation guide/profile developers to see what extensions already exist and leverage those rather than creating their own duplicate extensions FHIR's profiling (and associated validation, IG publication and testing) mechanisms make it easier to enforce consistent use of extensions within a particular jurisdiction or other implementation space (and to enforce the use of core elements where that's appropriate too). Most importantly, FHIR has an extremely active and responsive community (at http://chat.fhir.org) that helps guide implementers to appropriately and consistently using existing resource structures and/or 'standard' extensions rather than creating inappropriate or duplicate extensions. Those mechanisms won't prevent the inappropriate creation or use of extensions, but it's certainly helping. Where it does happen, it's generally where specifications/implementations are created outside the public view by individuals/projects that aren't engaged in the FHIR community. (Which is why it's super-important to encourage involvement in or at least awareness of the community by any one who is or might be implementing or creating specifications.) The other consideration is that, even where extensions do proliferate, their impact on interoperability isn't as negative as you might initially think: First, extensions fit within the standard schema. That means that I can receive, validate, pass on and even potentially store instances that contain extensions I don't recognize. As a result, the extensibility mechanism doesn't negatively impact the ability to process the instance as it does with other standards. In v3/CDA, extensions mean pre-processing prior to validation which adds complexity. And neither v2 nor v3 are amenable as generic persistence of extensions. Second, extensions are safely ignorable. If my system doesn't recognize them, I'm free to throw them away and be confident that if any of them contain essential information, it'll be present in the narrative for the end recipient to read. While some of the data might have better informed my decision support, filtering and other logic, ignoring them won't cause any of that logic to fail or produce incorrect results. (This is true because the non-safe-to-ignore extensions are separately flagged as "modifierExtensions".) Having a human readable representation as a fallback is hugely useful - whether the data is encoded in custom extensions, 'standard' extensions or even core elements. Third, the most important data to consistently exchange and understand is present in core. Even if there are a lot of extensions present, if I understand the core elements, I know the most important part of the story and I'm far further ahead than I would have been in most prior standards (and, even better, that story is shareable in a consistent way across provincial/territorial/national boundaries because FHIR instances uses a single schema everywhere). Extensions are, by definition, for stuff around the edge, so the fact that there's a risk of reduced interoperability there is mitigated by the fact that it's edge-case data anyhow. And governance allows it to be standardized and made consistent through profiles and implementation guides where clinical/business importance justifies. I don't think that governance can "ensure interoperability". It can improve it and increase the likelihood of it, but there are many nuances of interoperability driven by differences in culture, legacy, business process, perception of best practice, training, regulation, etc. that make "ensuring" full interoperability pretty much impossible. Governance can (and should) create improvements on the status quo and minimize unnecessary divergence. I also don't think the purpose of governance is necessarily to curtail the proliferation of extensions. Rather, the purpose of governance is to improve consistency of implementation in the spaces where consistency matters. For something like "patient health card version", "hijiri date of birth" or "boat across the street from", extensions are the appropriate solution and so long as there's a standard extension that's used consistently throughout Canada/Saudi Arabia/Netherlands respectively, that's fine. And it's also fine if some hospital embeds an extension that says "compliant against super-awesome-project-xyz" in a bunch of their instances that everyone ignores except one hospital-specific recipient. There could be thousands of hyper-local extensions like that in use and it wouldn't get in the way of interoperability. Attempting to impose strong governance on such extensions would be hurtful rather than helpful to healthcare interoperability - because if we make it too hard for implementers to introduce extensions for hyper-local requirements, they'll instead abuse core elements or 'standard' extensions to meet their business need and thereby reduce data quality. In terms of what we need to do here in Canada: One of the key lessons that went into building FHIR is that implementation (and thus correspondingly implementers) needs to be the primary focus. Design for the theoretical/best-practice/pet favorite doesn't get us anywhere because it doesn't actually get rolled out at the scale needed to make a difference. We need to be tuned into what implementers can do and are willing to do and focus on implementability (through proof-of-concept, reference implementations, connectathons, etc.) at each stage. A challenge that we have in Canada is that there are often two sides to the implementer space - the commercial software vendors and the jurisdictional implementations of bespoke province/territory-specific solutions. The latter has typically had more say than the former and the latter have also not done a great job of even pretending to want to be consistent with each other. (There are some exceptions, but they're still the exceptions, not the rule.) I'm not sure how we fix the politics of that, but if we want to take advantage of technologies like SMART and CDS Hooks, Apple's phone-based data repository and other truly revolutionary technologies (i.e. technologies that have the potential to, and in some places are, really reshaping how healthcare gets delivered), we're going to need to fix that "people" problem. The Apples of the world (because they can't be bothered) and app and decision support service developers of the world (because they don't have capacity) won't really engage in Canada if we can't agree on some basics like "what codes will we use for drugs and health conditions". I wish I knew how to get the needed governance in place. In the EMR space, a lot of our vendors are the same as the US vendors. And they're running flat out to keep up with the demands of the ONC, their commitments through argonaut and new payor/regulatory demands through Da Vinci. Given the size of the Canadian market, they're not going to pay attention to anything that demands significant variation from the direction they're already running and it's unlikely they're going to step up to take a leadership role here like they have in the U.S. On the smaller side of things, I think the community EMR vendors are wary of being asked to do more than they're already doing and certainly aren't positioned to lead something like a Canadian Argonaut. (I'd be super happy to hear disagreement from vendors on either of the preceding points...) The governance structures we once had through HL7 Canada and then through the Standards Collaborative are now gone. And Infoway is super gun-shy about standards of any sort, let-alone the notion of pan-Canadian standards. What we have left are grass-roots projects like the Canadian FHIR Baseline Profiles work and efforts to drive consistency around identifier URIs and things like that. That's good work, but I don't know if it will be enough to nudge jurisdictions or vendors to actually align. I think we need some assertive leadership, community building and formal governance. Just not sure how to get there from here :(
Derek Ritz replied to a discussion in Integrating the Healthcare Enterprise (IHE)
Cheap... Flexible... Interoperable... choose 2. YIKES!!
Lloyd -- thank you for these thoughtful responses! And yes, I'm happy to see that we separately teased out some nearly identical points regarding governance. I wonder if you could clarify a few of your points, please. I'm especially unclear regarding your assertions related to FHIR extensions. I do not dispute that there are technical differences between FHIR extensions and HL7v2 Z-segments -- and that these are important improvements. We agree, too, on the fact that they are essential; that's how we will develop a CA-Core, for example. What isn't clear is whether, in your view, a proliferation of FHIR extensions will undermine interoperability... and in this way, create the same "functional" challenge that Z-segments did. We agree -- "There is a place for governance, but there is also a place for flexibility." I think, however, that the role of governance is to ensure interoperability... and that this will likely include curtailing the proliferation of extensions that might otherwise occur in the absence of governance. Do we agree on this point, too... or not so much? Lloyd, you make excellent points about the technical value of a base+extensions approach vs. a maximal+restrictions approach. I like that approach, too, and for the same reasons you do. I also think I deserved to be called out for focusing on only one of Grahame's 3 laws -- especially when he bluntly stated that it's all about people, not technology. That's probably at the heart of my concern. Our problem in Canada wasn't (only) that we had the wrong wire protocol -- so how can a new one be the (only) solution? I'm curious to know what you think needs to be done so that FHIR... or anything else, for that matter... can go to scale and operationalize broad digital health interoperability across our Canadian care delivery network?
Lloyd Mckenzie replied to a discussion in Integrating the Healthcare Enterprise (IHE)
Cheap... Flexible... Interoperable... choose 2. YIKES!!
It's good that we're aligned on some key aspects of the governance piece. FHIR isn't trying to diverge from a model-based approach. What it is diverging from is two parts of the v3 methodology: 1. Having the modeling be part of the learning curve for the developers. (We want to keep the learning curve for those who need to build interfaces as low as possible.) In v3, the schemas and element names were directly driven by the RIM, which resulted in complex structures and non-intuitive names which acted as a barrier to uptake. We want a specification that a healthcare implementer with no HL7-specific training can look at and say "Yeah, that makes sense, I can do that". Neither v3 messaging nor CDA met that objective - and thus there was minimal uptake except where there was a top-down push. 2. Design-by-constraint doesn't work. V3 took an approach where the core specification tried to include everything that anyone might need with the notion that the specification would be tightened down as it got closer to the implementation space. The result was that design took way too long (it's hard to get consensus on 'everything' when new use-cases keep coming to the table) and the resulting artifacts were inevitably both too restrictive (causing different jurisdictions to introduce variations the broke compliance) and too abstract/flexible (resulting in different implementers solving the same problem by different mechanisms. FHIR certainly has a lot of flexibility built in, but not around the 'common' stuff. If you tell 3 different implementers to share allergy information and give them the v3 RIM (or the base CDA spec), you'll get wide divergence and minimal interoperability. (And they probably won't like you very much after trying to wade through and understand the spec.) On the other hand, if you give them the same task with the FHIR specification, they'll be a lot happier, a lot faster, and what they produce will interoperate a lot better. They might not all have exactly the same capabilities (some might capture reactions and severity, others might not) or use the same code systems, but at least when they're sharing the same information it'll be in the same data element. That's a huge step forward. The v3 RIM still underlies most of the FHIR resources. (Some resources such as StructureDefinition and ValueSet don't live in "RIM-space", so the modeling is still there. But it no longer gets in the way of providing a specification that's intuitive to implementers and the resources are tighter in ways that drive more consistency. Of course, "some consistency" isn't necessarily "enough consistency". FHIR dictates pretty strict expectations around some things (e.g. vital signs) but is a long way from trying to standardize every CBC, care plan or protocol. Realistically, we'll never standardize everything because we don't have consensus and/or the space evolves too quickly. We can, however, increase the standardization of the highest value pieces - and we can often standardize those in a use-case independent way. We can come to agreement that we're going to use CCDD for drug codes and SNOMED CT for condition and allergy codes and define where "health card version" should be sent without necessarily limiting the scope of those decisions to just "shareable health record" or "decision support" or "disease registries" or anything else. There will of course be additional expectations driven by those use-cases, but hopefully we can get sufficient alignment that an EHR could expose a single interface that meets the SHR, CDS and registry requirements.
Derek Ritz replied to a discussion in Integrating the Healthcare Enterprise (IHE)
Cheap... Flexible... Interoperable... choose 2. YIKES!!
David -- thank you for this! You're right, of course... ideally we would all love to be able to get all 3 at once and it does feel, a bit, like we're being asked to make a false choice. I fear there is a bit of persistent naivete, though, around how difficult it is to get both flexibility and interoperability. To get that, we need to be able to leverage an underlying information model (e.g. HL7 RIM... or OpenEHR's RM) to develop our data exchange models. We tried this approach. It proved not to be "cheap"... software developers needed to traverse a non-trivial learning curve before they could understand how (for example) the HL7 RIM works. Of course... software tooling can help address this (as it has with FHIR). But we bailed on the whole model-based notion once the Americans had decided it was "too hard". They were (largely) our software providers, after all. My gut instinct is that we'd need to embrace an underlying information model before we could operationalize Postel's law. If we were strict about being model-adherent... then any model-adherent message (even if I'd never seen the exact message schema before) could be ingested by a receiving system. In terms of being flexible enough for clinicians to get value out of the SHR, I think we may disagree. I think that we need to develop CA Core so that clinicians get value out of the SHR. This should, in my view, be the most scope-defining engineering constraint on the whole of that effort. Frankly, my biggest fear is that we'll back away from a Canadian vision based on broad interoperability. This is totally doable from a technical standpoint. Our challenge is sociotechnical, not technical. Our biggest challenge is governance... and governance is hard. We may find we've disassembled some of the "collaboration-supporting" infrastructure we will need to achieve consensus and go to scale with it.
Lloyd Mckenzie replied to a discussion in Integrating the Healthcare Enterprise (IHE)
Cheap... Flexible... Interoperable... choose 2. YIKES!!
Hi Derek, Some thoughts on your post 1. FHIR extensions have several important differences from v2 Z-segments: FHIR extensions are named in a globally unique way by a URI, so you don't have to wonder whether my ZPA.2.5 means the same as your ZPA.2.5 FHIR extensions are discoverable. If you receive an instance that contains an extension, you MUST have access to the formal definition of the extension. (If not, the sender is non-conformant.) In v2, the only way to find out what the elements in a Z-segment mean is to phone the interface analyst at the hospital that sent the message (and sometimes not even then :( ) FHIR extensions do, in fact, have formal definitions, which means there's a formal description of what the extension means, what the allowed values are, what other constraints exist, etc. FHIR extensions can appear where they need to, not only at the segment level. That makes it possible to extend names, identifiers and other complex structures that v2 provided no easy way to manage other than by trying to link equivalent repetitions FHIR has a solid registry infrastructure that makes it much easier to discover extensions that already exist and consolidate on the use of existing extensions rather than always inventing new ones FHIR has a robust profiling infrastructure (and starting to be decent tooling) to allow authoring of profiles that dictate what extensions are expected to be supported in particular context and where and when they must appear, which makes the process of governing the use of extensions much better than it was in v2. Extensions are not a panacea. They can be (and in places, are being) abused. They certainly allow for undesirable divergence. However, they're also essential. Without extensions, it becomes necessary to include everything in the core model. This results in a huge amount of bloat. Canadian developers don't want to wade through address parts designating "house boat across the street from" nor to have to google what a "hijri" date is. Extensions allow the core specification to be limited to those elements that most systems need and, through a profiling framework, to also standardize the more region-specific/discipline-specific/organization-specific requirements in a way that doesn't impose a cost on everyone else. 2. There is a place for governance, but there is also a place for flexibility. One of the nice things about FHIR is that it's much more amenable to agile development approaches. You can easily start sharing new data elements that not necessarily everyone in the interoperability community supports yet. And you can do that without breaking existing receivers. The narrative view ensures that any 'key' information is available to the consuming clinicians, while permitting participating systems to migrate to supporting the new discrete element in a time-frame that works for them. This elimination of the need for single "big bang" migrations (and the corresponding difficulty that results in supporting new features or diversity of use-cases) is one of the biggest benefits to FHIR's single-schema with extensions approach. 3. We've seen, through the v3 experiment, that standardization that's solely driven by top-down governance doesn't fly well. There's a need for a mixture. Yes, we need projects like US-Core, CA-Core, as well as more specific projects in areas like registries, diabetes, etc. to increase consistency and agree on requirements for interoperability in a specific space. But those won't always start at the pan-Canadian level. And there needs to be room for innovation at the jurisdictional and individual software product level because if that room isn't present, it'll be forced in - generally at the price of interoperability. 4. One of the design points for FHIR is that, as much as possible, it should be possible for systems to expose a *single* FHIR interface that meets the needs of multiple consumers. Systems consume the data they require and ignore the data they do not. This reduces maintenance costs because rather than having a separate API for each jurisdiction/use-case/etc., the software only needs to write code to expose its internal data store once. This reduces overall implementation costs, increases uptake and increases responsiveness of implementers to new requirements (because new requirements no longer come with the baggage of creating, testing and forever maintaining another separate interface). This design point does, however, reflect a significant change for specifiers. Specifiers are often used to locking down interfaces to exactly what they want - and only what they want. It means baking in the flexibility of allowing additional data to be present and defining the mechanisms to extract the data needed from within a broader collection. 5. I do agree that there's a need for governance. FHIR allows the same problem to be solved in multiple ways. It carries with it the benefit that even if solutions have different architectural approaches (e.g. REST vs. documents) the underlying data is typically at least easily portable. However, true interoperability does require a governance process that allows the community to say, "This is the architecture and the set of minimum data elements we agree to exchange to solve this problem". Good governance is hard. One of the other 'laws' Grahame has talked about in his past posts is that interoperability isn't a technical problem, it's a people problem. There's a need for people to agree and, even harder, there's a need for people to agree to change and to incur costs for the broader benefit of interoperability. One of the things FHIR did from the outset was to try to improve governance processes within HL7 to help ensure that the principles underlying FHIR were adequately reflected in the work coming out of the different HL7 work groups. The result hasn't been perfect, but it's certainly been significantly better than what HL7 has been able to produce with past standards. In terms of implementation guides, the governance and quality processes are still very much a work in progress. A significant challenge for us in Canada is figuring out how to ensure that there's similar good governance in place for the standardization work that needs to happen in the Canadian space. Infoway isn't as strong as it once was from a leadership capacity. We've lost several of the governance structures that would allow us to formally declare something is a "Canadian standard". More importantly, we don't have a deep and broad set of the implementer community engaged and paying attention and providing feedback in a way that would allow us to feel confident in both the implementability and the probability of uptake of any specification that we were to declare a "standard". In the U.S. they have a mixture of Argonaut (bottom-up, vendor led) and ONC (top-down, government imposed, though vendor influenced) that addresses this governance need to some extent - though in a far from perfect manner. In Canada, we don't really have anything that's national in scope with the same investment, influence or degree of involvement. The U.S. is actually doing a pretty good job of not abusing extensions and ensuring consistency of approach across implementation guides. If we don't figure out how to do the same in the Canadian space, we're not going to get nearly the same benefit out of the capabilities FHIR offers.

Events



Upcoming events:
No events

Forum

Cheap... Flexible... Interoperable... choose 2. YIKES!! 04/20/19
i sure do agree with your last points, Lloyd. Leadership is everything!
Cheap... Flexible... Interoperable... choose 2. YIKES!! 04/18/19
Thanks, Lloyd, for the very thoughtful and thorough reply. There's a lot to think about, as we continue to progress Canada's digital health agenda. I genuinely appreciate these ideas and suggestions and clarifications. All very helpful! :)
Cheap... Flexible... Interoperable... choose 2. YIKES!! 04/18/19
Hi Derek, The risk in proliferation of extensions really comes from two places: 1. Systems that choose to stick their data into extensions rather than conveying it in standard elements. For example, "I use a SNOMED code for gender, so I'll send...
Cheap... Flexible... Interoperable... choose 2. YIKES!! 04/18/19
Lloyd -- thank you for these thoughtful responses! And yes, I'm happy to see that we separately teased out some nearly identical points regarding governance. I wonder if you could clarify a few of your points, please. I'm especially unclear reg...
Cheap... Flexible... Interoperable... choose 2. YIKES!! 04/18/19
It's good that we're aligned on some key aspects of the governance piece. FHIR isn't trying to diverge from a model-based approach. What it is diverging from is two parts of the v3 methodology: 1. Having the modeling be part of the learning cur...
Cheap... Flexible... Interoperable... choose 2. YIKES!! 04/18/19
David -- thank you for this! You're right, of course... ideally we would all love to be able to get all 3 at once and it does feel, a bit, like we're being asked to make a false choice. I fear there is a bit of persistent naivete, though, around...
Cheap... Flexible... Interoperable... choose 2. YIKES!! 04/18/19
Hi Derek, Some thoughts on your post 1. FHIR extensions have several important differences from v2 Z-segments: FHIR extensions are named in a globally unique way by a URI, so you don't have to wonder whether my ZPA.2.5 means the same as yo...
Cheap... Flexible... Interoperable... choose 2. YIKES!! 04/18/19
Interoperability needs to be priority #1. Flexible is a nice to have. Cheap is a reality. That being said, we need to look at the balancing of interoperability and flexibility. We may have higher flexibility and lower interoperability if we can sh...
Cheap... Flexible... Interoperable... choose 2. YIKES!! 04/18/19
This is meant as a spark-a-conversation piece... please, let's DISCUSS this very important topic. Recently, I heard a presenter cite, with some reverence, Grahame Grieve's "..." which basically posits that there is a trade-off between having digit...
Updating IHE's FHIR Profiles to R4... and more details about Project Gemini 04/11/19
Derek thanks for sharing this update and for promoting the FHIR education session at the HL7 International working group meeting in Montreal next month. I wanted to let folks know that Infoway is hosting a free Introduction to FHIR webinar next...
Updating IHE's FHIR Profiles to R4... and more details about Project Gemini 04/10/19
IHE is working its way through the portfolio of FHIR-based Profiles and refreshing these to conform to Release 4. In parallel -- IHE and HL7 and moving forward with their FHIR-centric collaboration: the Gemini Project. Updates regarding both of these...
IHE International and SNOMED International announce global license agreement 04/10/19
From the IHE newsletter... here's a hot-off-the-press joint announcement related to operationalizing global interoperability. ... Agreements such as this are examples of how IHE Profiles make standards-based digital health more digestible and...
IHE USA webinar re: C-CDA on FHIR 04/09/19
Hi all. ... IHE USA and HIMSS will be hosting a Webinar on June 3rd related to their .... The webinar specifically relates to the idea of exchanging Consolidated CDA (C-CDA health summary documents) using FHIR. This webinar could provide some u...
IHE and the EU International Patient Summary (IPS) Presentation and Montreal FHIR Connectathon 03/12/19
X-Post from HL7 Canada Community: Thanks for posting this, Ron. I was not able to attend the webinar, but found the slides very relevant to a growing need to find ways to support interoperability on a global scale. In fact, I would like to see Canad...
IHE and the EU International Patient Summary (IPS) Presentation and Montreal FHIR Connectathon 03/11/19
Hello Canadian IHE Community. Here is a link to the ... given by Rob Hausum of HL7 International and Giorgio Cangioli of CEN 251 (and Chair of the Italy International Affiliate) at the March 5th 2019 HL7 International Community call. If you wer...

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.

Archive ( 4 Documents )

IHE Canada Liaison Role Description

Published on Jul 19, 2018 by Andrea MacLean

Video

The IHE Connectathon - A multi-perspective webinar
08/05/15
Attila Farkas

Solutions

  • Canadian FHIR Registry
  • Canadian URI Registry
  • FHIR Terminology Service API
  • HAPI FHIR
  • HAPI v2
  • HL7 Explorer
  • InfoRMS
  • 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.

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.

View projects in the Canadian FHIR Registry

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.

Search the Canadian URI Registry (alpha)

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

 

 Tools

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

 

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.

 General Documentation

 Implementation and Exchange

 Tools

 

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

 General Documentation

 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 (Inofway) 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.

  • For all non-jurisdictional and Infoway owned subsets, email the completed form to This email address is being protected from spambots. You need JavaScript enabled to view it.
  • All other requests must be sent to the Jurisdictional Representatives for OIDs
.

OID submission guidelines

  1. Jurisdictional Teams require 5-7 business days to process each request. It will be incumbent on the requestor to reply within this time frame to any questions and follow up as required. Any failure to do so will result in an automatic rejection and require resubmitting the request.
  2. The Requestor must post the OID requests on the following forums ONLY after consulting with the Jurisdiction/Infoway SME:
  3. Forum posts shall have the following format:

    Subject: New Namespace/CodeSystem/Subset OID Request
    • OID Description: “A description of the OID”
    • OID Symbolic name: Symbolic name guidelines
    • Responsible Body & Contact Information
    • Proposed FHIR URI: URI as per URI Guidelines
    • To be published: Canadian URI Registry/Terminology Gateway

  4. There will be a wait period of 5 business days for the communities to react to the forum post with comments, questions or requests for clarification.
  5. FHIR URIs must be proposed for all jurisdictional and non-jurisdictional OID requests according to the URI Guidelines and must be published in the Canadian URI Registry. Publishing the URI is an optional but highly recommended step. The Requestor will submit a validated FHIR® NamingSystem resource object based on the NamingSystem profile to their jurisdictional representative who will then upload it.
  6. FHIR URIs must not be proposed for Subsets to be published on the Terminology Gateway as they will be generated automatically.
  7. The Forum post will be updated with the new OID.

OIDs Registration Process

Registration Forms

General Documentation

 Tools

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

 General Documentation

 Tools

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

 

 Tools

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.

 

 Implementation Guidelines & Resources

informs 40x40 Content Changes 

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

Derek Ritz
Derek Ritz
ecGroup Inc.
OFFLINE
Contact
Andrea MacLean
Andrea MacLean
Canada Health Infoway
OFFLINE
Admin
Linda Monico
Linda Monico
Canada Health Infoway
OFFLINE
Admin
Céline Veilleux
Céline Veilleux
CreativAxion IT inc.
OFFLINE
Member
Laura Bright
Laura Bright
LJB Consulting
OFFLINE
Member
Parul Sinha
Parul Sinha
n/a
OFFLINE
Member
Sean Murray
Sean Murray
Box
OFFLINE
Member
Beverly Knight
Beverly Knight
Canada Health Infoway
OFFLINE
Member
Deepti Razdan
Deepti Razdan
cd-ed
OFFLINE
Member
Katie Williams
Katie Williams
NSHA
OFFLINE
Member
Ron Parker
Ron Parker
Parker Digital Health Consulting Inc.
OFFLINE
Member
Tracy Wutzke
Tracy Wutzke
CD-ED
OFFLINE
Member
Ovidiu Girlan
Ovidiu Girlan
MOHLTC
OFFLINE
Member
Melody Scory
Melody Scory
n/a
OFFLINE
Member
Melvy Sanchez
Melvy Sanchez
CDED
OFFLINE
Member

InfoCentral logo

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

Contact Us



Login Register