Hi all.

There is a lot of news from the first two months of 2019. I'm going to try to give a very-short summary of some of the activities at IHE and then focus on a particular point where I very much want the IHE Canada community to wade in with ideas and comments. First... a brief summary of news:

• We have a new logo! Check out our swishy new IHE Canada logo on the community splash page. We may yet do some tweaks... but it is (we hope) representative of IHE's "positioning" in Canada's digital health ecosystem.
• IHE and WHO have begun a collaboration process. IHE International's Board co-chairs had an initial meeting with one of WHO's digital health leads to kick off a process that will, hopefully soon, result in the establishment of an IHE WHO deployment committee. This committee will operate somewhat like IHE Europe -- except that membership will not be geographic, it will be based on national income status (e.g. low and middle income countries). More news as this collaboration develops.
• Related to the above news -- WHO has established a Department of Digital Health. How cool is that?!
• IHE profiles were tested at the North American Connectathon at the end of January and demonstrated at the HIMSS Interoperability Showcase in February. Not surprisingly -- there was a lot of interest in IHE's family of FHIR-based profiles.And this leads nicely into our main focus topic.

As there should be -- there is a lot of interest in IHE's growing family of FHIR-based profiles. In particular, I'd like to draw our community's attention to what might seem to be an innocuous work item in IHE's IT Infrastructure technical committee this year. In fact, I think this work item is crucially important.

There are, at present, no clearly defined normative behaviours defined in the FHIR standard related to a patient "merge". For clarity -- a "merge" event occurs when it is found that, in error, two demographic records have been set up for the same individual -- and we fix this problem. I've put the word MERGE in air-quotes because there are, technically, a number of ways to associate the two IDs with each other... and this is, in fact, part of the problem.

My reason for drawing attention to this gap is that it is a gap that can create patient safety issues. If there is an ID for Derek, recorded health data will be associated with that ID. If, in error, another ID is set up for Derek -- there could be health data collected that is keyed to that ID, too. If the error is found and fixed -- we need the health data that was associated with the two IDs to be "merged" so that any request for all of Derek's data will return ALL of Derek's data, regardless of whether it was originally linked to ID-1 or ID-2.

As I said -- IHE's IT Infrastructure committee is working on this problem. For IHE International members (and I hope you are all members!) the work item is Patient Identity Management using FHIR (PIMuF). I think closing this gap is a big deal -- and I hope those with FHIR chops can wade in with your thoughts about how it should be done.

The gist is: just like any other standard (e.g. ISO, or IEEE, or SNOMED, etc.) the FHIR standard is not inherently patient-safe... we have to implement the standard in a way that is patient-safe. I see the PIMuF work item as an example of IHE adding the important value we need it to add: it is creating a Profile that describes mandatory behaviours that apply, in this case, to patient safety.

We have to ensure, as we start to more broadly adopt the FHIR spec, that we are doing so in ways that force us, as health informatics professionals to adopt the same credo that our clinical colleagues adopt. We have to make sure that our digital health deployments add value... and that they also do not harm.

I welcome comments and ideas -- and please, for those who have expertise in this area, wade in with your thoughts on the PIMuF spec.
Warmest regards,
Derek