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.

Back to Basics: Rhizome

I started the Rhizome reference implementation a year ago as a way of demonstrating how a combination of client-side services, constructed using Angular and Cordova, and server-side adaptation and integration, constructed using Worklight, could be used to build a mobile health app for the enterprise. The pieces are there, and I have come to their conclusion that the server-side integration, while important, should really just be built into the application server, which hosts the server-side API. If the server-side API is built to an industry standard like NIEM or HL7, then the burden of integration is lightened, and maybe it could take place within a resource-based suite of client-side services.

The greatest illumination for me came when I stopped trying to build the server back end and with a client app extending it, and instead focused on a client app with an HL7 FHIR standardized interface. Do I have to do a lot of adaptation on the server? Depends on the data source, but... In an ideal world, thee data source has low impedance, and it is already FHIR JSON. In that case, an Angular app built around the core FHIR resources just works.

So I'm taking my references implementation in a slightly different direction, less coupled to an enterprise mobility platform, more reliant on a strong client-side architecture which is resource-based and standardized for the health industry, leveraging profiles from organizations like IHE and HL7 where possible, and probably with a more specific focus on care plans and questionnaires, without losing focus of prescription medications.

I'm also going to try posting more frequently, for a variety of reasons, so please feel free to comment. I have really enjoyed working with AngularJS over the last year, and I know I'm not alone in this.

Working with multiple standards for Health

I've been doing some reconsidering over the summer about the existing profiles and use of health standards in Canada, standards like HL7 v2, v3 and CDA. Primarily, v2 is used for ADT (Admission, Discharge and Transfer), but that's a huge chunk of workflow. The reason HL7 v2 is used so pervasively in Canada is because the clinical systems in use in hospitals (Cerner, Epic, Meditech, etc) use v2. At the time the current blueprint for electronic health record adoption was planned, there was an expectation that the U.S. would undergo a process of migration to HL7 v3, and that never happened, and this has left us with a foundation built around HL7 v3 Messaging and its core principles, with a thick transformation layer between this foundation and clinical systems in hospitals.

Obviously, this creates a space of impedance mismatch where continuity of service is put at risk. As a way of mitigating this risk, v3 Messaging is augmented with a companion specification, CDA, the Clinical Document Architecture, which promises to supports health documents like Continuity of Care, Health Questionnaires and Care Plans, as well as business cases using CDA to handle data in migration. Again, in the U.S., HL7 CDA has been used as an alternative to v3 Messaging to support exchange of health information, and in Canada we may benefit from following that path, but if we do, we should be aware that this path is probably morphing as we speak into a thing called "C-CDA using HL7 FHIR XML".

As discussed here and elsewhere, FHIR is a successor standard to all three HL7 standards, providing support for JSON and REST which have not been previously available, as well as the ability to essentially re-implement CDA using a similar XML standard. FHIR has a lot of potential in Canada and abroad in order to enable mobile health applications, but in order to design an build these applications, we need to reconsider the iEHR architecture on which we are currently building.

To that end, I have a number of suggestions:

1. Foster communication between systems using like standards: for instance, we have invested substantially in communicating clinical information between clinical systems in hospitals and the foundation layer of Labs, Pharmacies and Diagnostic Imaging; but can we find quick wins through improved intercommunication amongst the domains in the foundation, or between the enterprise systems that use v2 natively?
2. Create an adaptation layer supporting lightweight secure access: this is where FHIR may play a part, used to expose high value information across the enterprise. The danger in providing an incomplete picture is that people will take it for a complete picture; because FHIR is rooted in extension, composition and aggregation, it may provide a way to build a fuller picture of longitudinal patient information.
3. Registries like Provider, Client and Location should provide more comprehensive Identity Assurance; again, this really means removing continuity gaps within the services available to a patient, thus providing the history of interactions which is a necessary part of guaranteeing identity.
4. Create an application layer that supports developing mobile and web applications that can connect directly to the resources exposed in step 2.

This last step is what I have been reconsidering. As a document standard, CDA has had some success as a technology for mobile health in the U.S., under the auspices of Meaningful Use; however, a mobile health application built to natively use HL7 FHIR JSON and XML, even during the early adoption phase, would still be a solid target for reuse, and it is this capability for reuse that I find compelling, more than using HL7 FHIR to build new registries, repositories, or even greenfield projects. Simply put, if you build a health app using HL7 FHIR as an interface specification, you may still need to perform server side adaptation, but more than likely you would anyway. The benefit from doing so is that you are constructing a stationary target, and that is invaluable. 

HIMSS14 and the Culture of Interoperability

Interesting follow up piece to HIMSS14 from Deloitte in WSJ, and a few thoughts on human and machine interoperability. The message:

Interoperability standards are often overemphasized in discussions of data sharing, and it is important to understand that standards for interoperability already exist and can be implemented. What is critical is shedding the light on building interoperability into vendor design of medical products versus just building standards. Enlisting provider buy-in is one way of supporting this goal.

 

We have the standards, now we need to apply them. For modern interoperability standards like HL7 CDA, for instance, the barrier to entry is incredibly low – you can wrap an existing PDF in an appropriate header, which is essentially boilerplate, and you have satisfied the lowest level of CDA compliance. What is important to understand here is that “clinical interoperability” does not have to imply “machine-readable” except in the broad sense of syntactically capable of exchange between two systems or components. The lowest level of interoperability is exchange of human-readable content within a structure that can later be extended to support machine-readable coding. 

From the HL7 Standards blog:

The primary characteristic of a CDA document is that it must be readable by humans. The CDA specification states that, “human readability guarantees that a receiver of a CDA document can algorithmically display the clinical content of the note on a standard Web browser.” This requirement means that a clinician or patient can take a CDA document and display it on any computer with a web browser without the need to load any additional application.

The real work in interoperability, as we know, is in rationalizing and aligning code-sets. That's a governance issue. Exposing human-readable content in a structured fashion is important, as described above. But is it possible to access a system's supported vocabulary  and conformance profile using a standard Web browser? Maybe that would be useful as well. Incidentally, that's one of the ways FHIR goes beyond CDA. Clinical interoperability is about exchanging a specific type of information, for instance, exchanging clinical information about a patient that allows an exchange partner to leverage what we already know about them. One of the things we should be able to exchange is a conformance profile that defines how such an exchange can take place.

This is at the heart of an ongoing debate in Canada about the future of both CDA and SNOMED-CT. We have existing standards and terminology sets, so aren't these adequate to the task? What can we learn from this debate about what factors contribute to the success or failure of clinical interoperability projects? How can we reduce complexity, while increasing availability of information and metadata?

Using XSD 1.1 with HL7 as a Schematron replacement

Several years ago, I posted an article on IBM developerWorks about using OASIS CAM and David Webber's CAM Processor tooling to extend HL7 v3 schemas to better handle the extra conformance levels required by the HL7 RIM, particularly dealing with null flavors. At that time, CAM Processor was relatively new, and CAM is now reaching a very good level of maturity in the NIEM community; however, I suspect that HL7 specifications will always be more demanding than NIEM, in part due to the complexities of the RIM. The best alternative has always proven to be XSD 1.0 + ISO Schematron. At the time, I had considered using XSD 1.1, which provides assertions, but at the time, XSD 1.1 was still in development, and the CAM tooling just worked.

Recently however, it dawned on me that XSD 1.1 is now a W3C Recommend, and it has evolved, much like CAM, to include features that originated in Schematron. Actually these ideas didn't originate in Schematron, but that's another story.

As opposed to OASIS CAM, which really combines the core strengths from Examplotron and Schematron - using a reduced instance XML instead of a hierarchical grammar, and using XPath to define assertions - XSD 1.1 retains the hierarchical grammar, adding Schematron-like assertions to the extension/restriction process which is already built into XSD. So, to test data-type assertions on an element, you restrict the type definition for the element; to test conformance assertions on an element, you extend the type of the element to include any necessary assertions.

For example, in the HL7 RIM, an element can be Optional, Required or Mandatory - with an extra level, Populated, in some realms. For Optional, Required or Populated elements, a nullFlavor attribute is permitted in place of absent valued information, to describe why the information was absent. The phrase null flavor is confusing, but really it's just a reason why the information is absent. For Mandatory elements the nullFlavor attribute is forbidden.

In an existing XSD schema, you can determine which elements are Mandatory because they have minOccurs which is greater than 0, and isMandatory is true [ed. this has been edited]:

<xs:element name="processingCode" type="CS.CA"
   minOccurs="1" maxOccurs="1">
   <xs:annotation>
      <xs:appinfo>
         <mif:attribute name="processingCode"
             minimumMultiplicity="1" maximumMultiplicity="1"
             isMandatory="true" isImmutable="false">
            <mif:businessName name="D:Processing Code"/>
            <mif:annotations>
                <mif:appInfo>
                    <mif:mapping sourceName="Sample">
                        <mif:text>
                            <mif:p>[MSH-11.1]</mif:p>
                        </mif:text>
                    </mif:mapping>
                </mif:appInfo>
            </mif:annotations>
            <mif:type name="CS.CA"/>
            <mif:vocabulary>
                <mif:conceptDomain name="ProcessingID"/>
            </mif:vocabulary>
         </mif:attribute>
      </xs:appinfo>
   </xs:annotation>
</xs:element>

In order to add an assertion using the new features in XSD 1.1, we need to remove the type attribute from the element, and extend it as a complex type:

<xs:element name="processingCode" type="CS.CA"
   minOccurs="1" maxOccurs="1">
   <xs:annotation>
      <xs:appinfo>
         <mif:attribute name="processingCode"
             minimumMultiplicity="1" maximumMultiplicity="1"
             isMandatory="true" isImmutable="false">
            <mif:businessName name="D:Processing Code"/>
                    . . .
            <mif:type name="CS.CA"/>
            <mif:vocabulary>
                <mif:conceptDomain name="ProcessingID"/>
            </mif:vocabulary>
         </mif:attribute>
      </xs:appinfo>
   </xs:annotation>
   <xs:complexType>
      <xs:complexContent>
         <xs:extension base="CS.CA">
            <xs:assert test="not(@nullFlavor)"/>
         </xs:extension>
      </xs:complexContent>
   </xs:complexType></xs:element>

If additional assertions are required, they can be added to the same extension; however, in this case, the only assertion we require is to ensure that the Mandatory element does not have a null flavor when we validate an instance message. All that remains now is to change our XML editor so that it is using Xerces 2.11.0 or higher, which supports XSD 1.1, and when we validate a message, we will be alerted if there is a processingCode element which is null flavored.

Rhizome Business Value

Rhizome is a resource-based mobile demo I am building. It was originally intended for an HL7 FHIR connectathon to build out a security layer, and since developed into a companion to the PMIX Open-XDX API demo on VerifyXML.org, demonstrating using mobile JSON and XML.

Rhizome stands for "Resource-based Health Information Zone for the Mobile Enterprise"... the name is intended to be tongue in cheek, and the "R" could stand for REST, "E" for Exchange... but there is a buried meaning here as well: a rhizome like ginger or bamboo is diageotropic, meaning that it grows laterally; and the Rhizome application by design supports concepts like cross-jurisdictional exchange because it is resource- and scheme-based. It goes lateral.

In order to succeed in the enterprise, mobile exchange needs to be built on resource-based open web standards, which support making cross-jurisdictional data exchange work. This doesn't mean that the comprehensive approach taken by HL7 v3 is wrong, but we also need to support less complicated protocols like JSON and REST, using an agile approach towards content creation, consumption, collaboration and curation. Examples of this are projects like GreenCDA, HL7 FHIR and Open-XDX. Rhizome is an example of this also.

French literary theorists Gilles Deleuze and Felix Guattari introduce their A Thousand Plateaus by outlining the concept of the rhizome (quoted from A Thousand Plateaus):

• 1 and 2: Principles of connection and heterogeneity: any point of a rhizome can be connected to any other, and must be
• 3. Principle of multiplicity: only when the multiple is effectively treated as a substantive, "multiplicity" that it ceases to have any relation to the One
• 4. Principle of asignifying rupture: a rhizome may be broken, but it will start up again on one of its old lines, or on new lines
• 5 and 6: Principle of cartography and decalcomania: a rhizome is not amenable to any structural or generative model; it is a "map and not a tracing"

Jekyll/Prose.io

so, healthcare.gov: github/Jekyll/prose.io, and this is the Agile NoCMS approach now, replacing drupal as a shortest path content for anything solution? Weird, wild stuff.

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®

Firefox OS and Mobile Health

I have to say, I am very excited about Mozilla's Firefox OS, formerly Boot to Gecko, a Mobile OS built on web standards like HTML5, CSS and JavaScript, powered by a small Linux kernel. The OS is going to target less expensive phones, without requiring the power that Android or iOS do. If you were thinking PhoneGap, a Firefox OS app is much simpler than that. Why am I embedding in WebKit when I can boot to Gecko?

So the downside will be market penetration. In Canada or the States, or the UK. In Brazil, in Mexico, in eastern Europe, these phones could hit a sweet spot and build a strong developer community.

And this is why I'm excited. The real strength of mobile health is not going to be iPhone apps for American Doctors; it's going to be useful tools for areas that aren't already serviced by Epic or Meditech... In LMIC countries, a suite of mobile medical tools, and particularly one you might modify or extend yourself, that will be invaluable.

The developer phones are cool and orange as well.

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...

Structured Product Labeling...

I am currently reading about SPL (Structured Product Labeling), an XML-based standard used in the pharmaceutical industry, engineered to reduce pharmaceutical error. The SPL Standard, DailyMed, and the Consumer – DCLnews Blog By DCL's Vincent B. Donadio, Editorial Contributions from DCL's Howard Shatz In 2005, the Food and Drug Administration (FDA) implemented an XML-based standard for drug labeling (among other thi...

Via Health Intersections: Resources For Healthcare

Resources For Healthcare (RFH): Grahame Grieve's proposed response to the HL7 Fresh Look Taskforce, using 37 Signals' uberREST Highrise API as a jumping off point.

RFH defines a RIM-based ontological framework for Resources For Healthcare, based around an exchange, data dictionary and workflow management.


Letter to RFH readers

Letter to RFH Readers. Grahame Grieve 13-Aug 2011. This specification arose from the remit of the HL7 Fresh Look Taskforce: if HL7 started again from scratch with a new specification, what would a goo...

So, what's important about this? This proposal draws on the HL7 v3 RIM, the Reference Information Model that underlies the HL7 specification. The RIM is a pictorial object model which defines the life cycle of the different messages that comprise the HL7 clinical domains. Because health information is very much workflow based, the RIM-based part is important. moving away from a service architecture towards a REST architecture is indicative of a general shift towards simplicity in the IT industry as a whole.

The timing of this proposal is very much driven by the questions raised by the HL7 Fresh Look taskforce. I recently joked that HL7 v3 is still at a turning point, like one of my son's Choose You Own Adventure books. This screen capture from Graham Grieve's Health Intersections blog recently is perhaps an indication of the signposts facing HL7 v3:

I'm crossposting this to my personal weblog...

I'm crossposting this to my personal weblog for further ingestion. This is partially an experiment in google+... when the article (which I shared to blogspot by email) receives the message, it will post as a draft, since google+ sends blogger (along with the original post here), the credentials I am using to transmit the post... Question: How to store a CDA document in a relational database « Health Intersections Pty Ltd Question: How to store a CDA document in a relational database. Posted on August 16, 2011 by Grahame Grieve. 2 commentsLeave a comment. A question (by the ask me a question link above): I am trying to...