Some Canadian Context for HL7 FHIR

I work in Healthcare Messaging in Canada; specifically, I work in messaging in British Columbia, where we work primarily with Point of Service applications and Clinical Information Systems that generate and consume messages in the HL7 v2 pipe and caret notation, with a foundation of registries and repositories that use a version of HL7 v3 Messaging XML. More or less, this follows Canada Health Infoway's iEHR blueprint; however, following Infoway's original blueprint, we would have HL7 v3 at the Point of Service as well as the foundation.

HL7 v2 is still used extensively in other Canadian jurisdictions. Some use v2 almost exclusively. In Canada, we have a mix of v2, v3, with some CDA. The United States, on the other hand, never embraced v3, creating a desperate need for a better messaging layer. In this case, FHIR will accomplish things in the U.S. that v3 could not, and that leaves Canada in a challenging position - continuing on with further investment in HL7 v3 makes little sense. Like CDA before it, FHIR can be used to augment these projects; there are enough similarities between FHIR XML and v3 Messaging to make this plausible.

Ongoing CDA projects in Canada are bound to continue as such, which will be worth paying attention to as CDA projects in the States start shifting to HL7 FHIR as an implementation standard. The message from Infoway recently here is to use the appropriate standard for the work at hand, and I expect this message to percolate on both sides of the border; but what does this really imply? How do you decide? For new business cases which would previously have required a document standard like CDA, HL7 FHIR is going to be compelling, as well as low risk, local, and greenfield projects.

Worth noting is the four ways that FHIR can be used. As previously discussed, FHIR supports both Messaging and Document use cases; but, perhaps more importantly, FHIR also supports both REST and Service use cases. In addition, FHIR is in many ways custom built for the security and transport requirements of mobile use cases, and contains resource definitions that will enable social use cases like circle of care and information provenance. For existing health information systems and applications, as well as new, FHIR creates new ways to expose, access, and share information; providing not only tools, but also challenges.

Yosemite Project and other Chimera

In Greek mythology, the chimera  was a monstrous fire-breathing hybrid nightmare composed of the parts of more than one animal, a lion with the head of a goat rising out of its back, and a tail with a snake's head; a nasty piece of business, eventually dispatched by Bellerophon with some assistance from Pegasus.


Chimera was also the subject of a presentation by Jeni Tennison, OBE, of the Open Data Institute and W3C TAG, at XMLPrague 2012, entitled "Collisions, Chimera and Consonance in Web Content." In this presentation, she introduces a compelling argument that suggests that currently, in the web, we are dealing with four different formats: HTML, XML, JSON, and RDF.

In many ways, these formats complement one another. Sometimes, they clash, creating impedance and dissonance, and sometimes they merge, forming weird and wonderful hybrids. Tennison's presentation is really quite remarkable, and well worth watching as each of these formats evolves.

As I have previously mentioned, another set of presentations, from Dataversity and SemanticWeb.com, are also worth watching and paying attention to. These deal with the Yosemite Project, ongoing work which intends to position RDF as a Universal Healthcare Exchange Language. This work is important in part because it directly addresses how to go about migrating and transforming between formats, once you can establish a common representation using RDF. In many ways, this is a mythical undertaking, but also very promising.

For instance, with the work underway with Project Argonaut and HL7 FHIR, you are looking at a standard for healthcare that comes in two flavours, XML and JSON; however, like its predecessor HL7 CDA, FHIR relies on a human-readable portion, which in this case means HTML5. Add to that the work underway with Yosemite - go watch the presentations! Now you have an ecosystem that supports appropriate use of HTML, XML, JSON, and RDF - the subject of  Dr. Tennison's XMLPrague presentation - now in the context of healthcare. This is really what John Halamka has referred to as the "HTTP and HTML for healthcare".

If you broaden your horizons just a little, you will see some of the work which is also being carried out by Health & Human Services and the NIEM Health Domain, as a counterpart to the work of HL7 International. NIEM is primarily an XML-based standard, but in the last couple years, the underlying tooling there is expanding into UML-, JSON-, and HTML-based representations. With the support of some underlying ontology work, perhaps in concert with Yosemite, NIEM too could be used to create linked health data. These are all very exciting, very important things that are happening very very quickly, and it is a great time to get involved with some of these projects and initiatives.

Project Yosemite, SMART on FHIR, and the Argonauts

The Argonaut Project is a collaboration between Health industry vendors like McKesson, Epic, Meditech and so forth, along with the Mayo Clinic and Beth Israel Deaconess Medical Center, to provide the necessary resources to complete the work of the upcoming HL7 FHIR DSTU (Draft Standard for Trial Use). As Grahame Grieve elaborates on OpenHealthNews, Argonaut is aimed at three particular pieces of work:

1. Security
2. CCDA to FHIR Mapping
3. FHIR Implementation Testing

This work is intended for completion by May 2015. As described, the Security piece initially involves SMART on FHIR®, a platform developed by Harvard Medical School and Boston Children's Hospital, implementing open standards for healthcare data, authorization, and UI integration. For authorization, SMART uses OAuth2, a profile for which will most likely become built in to the FHIR standard.

Josh Mandel, the lead architect behind SMART on FHIR® also spoke recently as part of a series on  of five presentations on Project Yosemite, held by SemanticWeb.org and DataVersity. Project Yosemite began a year or so ago with the Yosemite Manifesto, which establishes RDF (the Resource Description Framework that underlies the Semantic Web and Linked Data) as the best candidate for a universal healthcare exchange language. Project Yosemite follows two paths, "Standards" and "Translation", based on the premise that standards adoption is of primary importance, but that there will always be a need to translate between standards, and even between versions of the same standard.

The idea here is that once you build ontological mappings of various healthcare standards into RDF representations, then Semantic mapping tools like SPINMap and TopQuadrant's TopBraid can be used to construct robust migration/translation layers. This is the first step in producing a distributed network of Linked Health providers, similar to the work currently taking place with Linked Data. At this point, the presentation recordings from DataVersity are not yet all available, but they are definitely worth watching.

HL7 FHIR provides a potential successor to several HL7 standards currently in use internationally. Migration is a critical success factor here, and Project Yosemite presents a different way to approach migration. Perhaps coincidentally, RDF and FHIR are both resource-based approaches; RSS is a syndication format that emerged from work with RDF, and FHIR uses a similar syndication format, Atom, to aggregate and compose health resources, like Patient and Observation.

Project Yosemite benfits FHIR and Project Argonaut, Argonaut accelerates the first phase of ONC Data Access Framework (DAF) project. Project Yosemite is involved with ICD-11. This seems like lot of convergence, and the next 6 months will really show how much. It's a great time to get involved.

HL7 FHIR and Argonaut in Canada

I am Canadian, so for me, Argonauts play football, and by football, I don't mean soccer. The Argonaut Project is also the subject of a recent announcement at last week's HL7 Policy Conference in Washington, in response to the latest JASON Report. There appears to be a mythological theme emerging in Health IT, and I'm looking forward to an opportunity at some point to scream "release the KRAKEN!!!" or something similar. But not yet.

The Argonaut Project has the backing of a number of American EHR vendors, including Epic, Cerner, Meditech, McKesson, athenahealth, with additional support from Partners HealthCare, Intermountain Healthcare, Beth Israel Deaconess, and Mayo Clinic. The project extends involvement these organizations already have with HL7 International, and promises to deliver implementation guides related to an emerging HL7 standard, HL7 FHIR, by May timeframe 2015.

• athenahealth
• Beth Israel Deaconess Medical Center
• Cerner
• Epic
• Intermountain Healthcare
• Mayo Clinic
• MEDITECH
• McKesson
• Partners HealthCare System
• SMART at the Boston Children’s Hospital Informatics Program 
• The Advisory Board Company

This is a diverse group of collaborators and an aggressive timeline, but what does this mean for Health IT projects here in Canada?

Migration and Transformation

Whereas HL7 v2 uses "pipe and caret" notation, and HL7 v3 supports any wire format as long as it is XML, HL7 FHIR comes in two flavours, XML and JSON (which makes it particularly useful for mobile use cases). By design, FHIR is intended to provide a migration path for v2, v3, and CDA. This really reminds me of the intentions behind the development of XML in particular, as a sort of lingua franca for the web, and in that sense, XML has been very successful. As mentioned, for mobile and social use cases, a JSON-based standard for health information will be hugely beneficial as well.

In Canada, we have built a foundation of healthcare registries and repositories based on HL7 v3 Messaging, although the applications that are in place in Hospitals and other Health Information sources typically come from U.S. vendors including many of those mentioned above, which requires a transformation layer from v2 to v3 and back again. I'd like to imagine a world where both the foundation and the Hospital information systems can communicate using the same standard, or through an integration layer that uses a common standard. Argonaut is at the very least a step in that direction.

Documents and Messages

Here in Canada, we have built our information access layer for health around Messaging; in the U.S., Document-centric health prevails. Canadian projects may involve the HL7 Clinical Document Architecture (CDA), but these are more limited in scope than the foundational work which has been carried out involving HL7 v3 Messaging. Recent guidance from Canada Health Infoway is to use the most appropriate standard for the job at hand. In many cases, that will be v3 Messaging, simply because the work is already underway.

FHIR is quite clever in that it is based around Healthcare resources (Patients, Providers, Observations and so forth), a more granular approach than either CDA or v3 Messaging, and this is how FHIR supports both Message- and Document-based flow of information. This is crucial if your requirements are a hybrid, or if you are currently supporting one approach, but are aware that you will need to support the other. Simply put, FHIR dispels the holy war between Health Messaging and Health Documents. ("Unleash the KRAKEN!!!")

Example: Questionnaires

It goes something like this: you are tasked with creating a set of health questionnaires for a Canadian healthcare organization. Most likely, you will create PDF documents, but you might consider using CDA for a moment, because CDA provides an architecture for Clinical Documents. But that moment would pass. Now, consider this: the FHIR community has already held several connectathons involving questionnaires, and one of its members, David Hay, has already written a series of articles about extending the Questionnaire resource based on his experience.

So that's useful.

In particular, IHE (Integrating the Healthcare Enterprise) is currently developing multiple profiles using FHIR as a basis for mobile access - (MHD, PDQm, RESTful PIX). With Canada Health Infoway as the home of IHE in Canada, I am hoping that we can find uses for these profiles here as well. These profiles are under development, but if the consortium behind the Argonaut Project really wants to make a difference, they can throw their support behind IHE as well.

References

HL7 International Press Release
HealthLeaders Media - Argonaut Project is a Sprint toward EHR Interoperability
OnHealthCareTechnology - JASON: The Great American Experiment
HealthcareITNews - Epic, Cerner, others join HL7 project
John Halamka - Life as a Healthcare CIO - Kindling FHIR

Hard not to agree with this observation by Alex Howard about the newly branded U.S. Digital Services.

Given the anger, doubt and frustration prevalent in the public discourse around government IT, the only way public trust in the federal government's ability to use technology well for something other than surveillance and warfare will be through the deployment of beautiful, modern Web services that work. Jen Pahlka has explicitly connected government's technical competency to trust in this young century.

"If government is to regain the trust and faith of the public, we have to make services that work for users the norm, not the exception," she told to Government Technology, after leaving the White House. Mayors, governors and presidents are experiencing the truth of her statement around the country, from small towns to 1600 Pennsylvania Avenue.

The challenge here is to move beyond secure, mission-critical systems that work in insulated environments - but fail to provide high value - to focus on measurable outcomes, quick(er) wins, higher value services for citizens. This is the holy grail of digitization.

Tracking the convergence of NIEM and HL7

Every few years, someone asks "could you implement HL7 with NIEM" or vice versa; well, with enough resources, you can accomplish anything, but what I want to do here is consider how the two standards are converging, how they are divergent, and why. NIEM has had a Health Domain for several years, evolving under the auspices of HHS. You wouldn't know it from the LinkedIn group.

The two communities could really benefit from sharing an understanding that to save money on implementation and stakeholder engagement, they need tools which provide the ability to easily and visually review and alter exchange packages (IEPD, FHIR Conformance Profiles), to reach absolute consensus; and then generate terse and completely accurate validation packages and conformance suites, so as to increase ongoing information safety. We need to be able to put all of the important details on one page.


NIEM and HL7 are both messaging models based on an underlying information model, and whereas HL7 is moving away from design by constraint towards design by extension, NIEM has always relied upon an extension mechanism. The difference here comes down to the size of the NIEM problem space ("everything"), as opposed to HL7 ("healthcare"), for which you might be able to imagine a totalizing framework that encompasses all workflow in all contexts; however, for HL7 as well, a workable extension mechanism is proving to be essential to success, and this is a change from the paradigm established with HL7v3.

NIEM and HL7 are both moving towards support for multiple wire formats. In domestic U.S. markets, HL7 means either "pipe and caret" v2 or "quasi-XML-HTML" hybrid CDA, but internationally, HL7 is an XML standard which is outgrowing the business cases for XML, much like NIEM. For both of these standards to grow and implement future business cases, they will need to also embrace and support JSON, HTML, and RDF, and given time they will.

HL7 is moving away from a proprietary tooling set towards tooling which is readily accessible, like Excel, Java, and XML editors. NIEM already uses a similar toolset, and has several initiatives in play to support open tooling like CAM Editor and UML tooling. One of the difficulties we have run into with HL7 v3 is difficulty sharing visual models, since these are captured in proprietary tooling, and it is here that the NIEM and HL7 communities would both benefit from demanding better tooling. Put simply, shouldn't these two standards support and be supported by a common toolset which extends beyond XMLSpy or Oxygen? And, given time I'm sure they will.

This is something I feel strongly about. At their core, NIEM and HL7 RIM rely on XML Schemas, and yet, XML Schemas are not sufficient to the task. In the HL7 world, as far as v3 Messaging and CDA are concerned, ISO Schematron fills this gap. For NIEM, OASIS CAM performs a similar task; but there is a disservice here to both of CAM and Schematron, that these are treated only as validation tools, when in fact, they contain key pieces of business. The same is true of UML - these should be the tools we use to visually communicate the business to the business.

Some of the tools will be open source, some of them will come from the product world. If the NIEM and HL7 communities articulate their needs, the tool vendors will follow. In short, HL7 and NIEM are both going to need to converge on a set of XML-based tooling that goes beyond XML Schemas and Visio diagrams. The CAM tooling provides some of this. The Excel-based Resource Profiling in FHIR provides some of this. UML tooling provides some of this.

To reduce the burden of approval for stakeholders, both messaging standards need to allow modelers, implementers, and business stakeholders to meet in a room and review the details of a proposed information exchange on a single page, and this will provide high value. When this is happening, information safety increases because the resulting XML Schemas and documentation produced after this meeting will be simpler, more accurate representations of the business.
  

TermInfo Discussion at HL7 WGM Atlanta 2013 (SIM&A)

Okay, HL7's RIMBAA Working Group hasn't changed their name to SIM&A yet ("Simba"), but it looks like that is the name that is going to stick to reflect the group's broadened scope.

One issue that this and other working groups are determined to put to bed is that of negation, particularly with TermInfo vocabulary sets like SNOMED CT. The problem is that not all vocabulary sets support negation implicitly, by providing vocabulary terms that are already negated. SNOMED CT does. The big question then is, should you always use the implied negation in the vocabulary set if it is available; or should you sometimes, or never use it.

The alternative, for HL7 v3 at least, is to use a negation indicator, messaged as a negationInd attribute on the element in question... so this is effectively metadata, and the problem with metadata is that there is no guarantee that the receiver interprets it correctly, if at all. For many use cases, this probably doesn't matter much, but for clinical diagnosis and decision making, for allergies, for drug interactions, and even in the context of non-health applications like Corrections and Defense, Person-of-Interest queries need to properly take into account null flavours and negations; so there is a strong Public Health and Public Safety aspect to this discussion as well.

So it is an important concept, and people need to reach agreement on the correct way to do this; however, this issue goes back a number of years, so I'm curious to see where it goes. My own thoughts are that a better way to do this from the start would have been to use a tri-state negation indicator, which indicates "positive", "requires negation", or "implictly negated"... but it's too late for that now, and it always has been.

Here are the details from the RIMBAA forum (via Rob Hausum, MD, Hausum Consulting):

The TermInfo negation discussion at the Atlanta WGM will be held in Q1 Tuesday (tomorrow).  Following a brief introduction, we intend to devote the remainder of the quarter to this topic.  We would like to come away from the quarter with a concrete plan to create and provide guidance on this important topic.  That may involve a focused TermInfo ballot on negation, but the specific form and scope is still open for discussion.

For those who aren't in Atlanta, we expect to have remote participation capability via GoToMeeting (details below).  Please join the discussion, or, if you are unable to attend either in person or remotely, feel free to pass along any comments/questions/concerns.

Rob

GTM details:

1.  Please join my meeting.

https://www1.gotomeeting.com/join/912947024

2.  Use your microphone and speakers (VoIP) - a headset is recommended.

Or, call in using your telephone.

Denmark: +45 (0) 69 91 89 33

Australia: +61 2 8355 1031

Austria: +43 (0) 7 2088 1033

Belgium: +32 (0) 28 08 4342

Canada: +1 (647) 497-9371

Finland: +358 (0) 942 41 5770

France: +33 (0) 182 880 159

Germany: +49 (0) 811 8899 6925

Ireland: +353 (0) 19 030 050

Italy: +39 0 693 38 75 50

Netherlands: +31 (0) 208 080 208

New Zealand: +64 (0) 9 925 0481

Norway: +47 21 54 82 21

Spain: +34 911 82 9890

Sweden: +46 (0) 852 500 179

Switzerland: +41 (0) 435 0167 65

United Kingdom: +44 (0) 207 151 1806

United States: +1 (213) 493-0619

Access Code: 912-947-024

Audio PIN: Shown after joining the meeting

Meeting ID: 912-947-024

GoToMeeting®

Online Meetings Made Easy®

XML Prague 2012 conference sessions

XML Prague 2012 conference sessions: Opening Keynote - Jeni Tennison  The eX Markup Language? - Eric Van der Vlist XML and HTML Cross-Pollination: A Bridge Too Far? Robin Berjon and Norman Walsh What XML can learn from HTML; also known as XML5 - Anne Van Kesteren Panel discussion on HTML/XML convergence - Norman Walsh XProc: Beyond application/xml - Vojtch Toman Understanding NVDL - the Anatomy of an Open SourceXProc/XSLT implementation of NVDL - George Bina JSONiq: XQuery for JSON, JSON for XQuery - Jonathan Robie, Matthias Brantner, Daniela Florescu, Ghislain Fourny and Til Westmann Corona: Managing and querying XML and JSON via REST Jason Hunter Treating JSON as a subset of XML: Using XForms toread and submit JSON - Steven Pemberton RESTful XQuery - Standardised XQuery 3.0 Annotations for REST - Adam Retter Compiling XQuery code into Javascript instructionsusing XSLT - Alain Couthures Implementing an XQuery/XSLT hybrid - Evan Lenz Transform.XQ: A Transformation Library for XQuery 3.0 - John Snelson Building Bridges from Java to XQuery- CharlesFoster My first XSLT editor - Tony Graham A Wiki-based System for Schema and Data Evolution - Lorenzo Bossi and Alberto Trombetta Standards update XPath/XSLT/XQuery 3.0 - Michael Kay and Jonathan Robie Closing keynote - Michael Sperberg-McQueen

Grahame Grieve on National Projects and Standards

From his Health Intersections site, this is Grahame Grieve on National Projects and Standards, and the tension between the two. I'm a standards geek, and I live for this sort of discussion. In this very concise article, Grieve discusses why projects at the national level rely on international standards groups, and how this introduces stress factors into these projects. I also appreciate Lloyd McKenzie's comment about the interoperability across borders. This is one of the promises of using international standards, but in reality, it rarely comes up, and comes with it's own host of issues. Interoperability between two sibling releases of a standard can be trying enough, let alone between two nations localization to the same standard. But that is what makes the work exciting. National Projects and Standards « Health Intersections Pty Ltd   There's a difference between the goals of the national project, and the value proposition of using standards, and this difference can create considerable tension...

Health Documents v. Health Messages or Elements

Useful breakdown of same key factors in the use of Health Documents v. Health Messages by John Moehrke: Healthcare Security/Privacy: Critical aspects of Documents vs Messages or Elements Healthcare Security/Privacy. Discussions of Privacy and Security in Healthcare by John Moehrke. Topics: Consent, Access Control, Audit Control, Accounting of Disclosures, Identity, Authorization, Auth...

Tactics for Engagement

A useful set of tactics for engagement with a standard, via Graham Grieve:

How much should we engage with a standard? « Health Intersections Pty Ltd Health Intersections Pty Ltd. Home. About; Ask me a question about HL7; CDA Tools; Courses. V2 to CDA Mapping Course. Enrolment Form. Roadmap to Blog; Text Display Formats. HL7 v2 FT Type; HTML Colour...

Tactics for Engagement

A useful set of tactics for engagement with a standard, via Keith Boone: 

Healthcare Standards: Tactics for Standards Setting: Lead, follow, or get out of the way. I have to make up my travel budget annually every December/January. In order to do so, I have to look at the overall strategic picture for standardization, and then pick the tactics that I think I wil...