Clinical interoperability and FHIR

FHIR Developer Days came to a close the Friday before Thanksgiving in Amsterdam. FHIR mastermind Grahame Grieve capped off the proceedings with a keynote address:

International FHIR DevDays Keynote (Grahame Grieve) from Rene Spronk on Vimeo.

Graham discusses FHIR's evolution beyond "draft" status and some of the philosophical and practical considerations as the standard grows up:

• FHIR will now be a "working standard," reflecting the fact that it is being used in production settings, but not yet etched in stone
• Levels of maturity for advancing the standard - which are largely community-driven - toward becoming "normative" 
• Packaging FHIR resources and making them more accessible and easily-interpreted, with a process that can be better understood by non-programmers
• The importance of considering who is served by data interoperability, not simply the flow and efficiency of information exchange; 

To this last point, for those trying to place FHIR within national interoperability efforts, Grahame attempts to lay out the ultimate goal of the standard development:

Data interoperability is all well and good but it's not the outcome that we need. The outcome that we need is clinical interoperability... My (definition) of clinical interoperability is the ability to transfer patients between care teams and provide seamless provision of clinical care. That is the interoperability that matters and will make a difference to people's lives.

What is considered data continuity for healthcare practitioners may not serve the needs of patients; yet the goal of a truly patient-centered, portable record will have to prioritize the healthcare user above all else.

***

There's still a lot to unpack from Amsterdam, In case you missed it, Developer Days also featured:

• Presentations from FHIR principals Lloyd McKenzie and Ewout Kramer
• API development in Java and .NET
• A "cheat sheet" with tons of useful FHIR info (compiled by Developer Days host Furore)
• An announcement that IHE is updating FHIR Profiles to align with DSTU2
• An announcement of a Notepad++ plugin for FHIR
• Trophies!

See you around the FHIR place.

FHIR Developer Days in Amsterdam

Amsterdam (CREDIT: Massimo Catarinella)

International FHIR Developer Days takes place this week (November 18-20) in Amsterdam. The event is hosted by Furore, a Dutch health IT company that has been active in FHIR development. Furore maintains an open-source FHIR test server called "Spark."

The three FHIR project leads ("FHIR Chiefs," as we like to call them), Lloyd McKenzie, Grahame Grieve and Ewout Kramer will all be in attendance. The event promises to be another great opportunity for cross-industry training and collaboration.

And, as with all FHIR Connectathons, there are tracks. Via the FHIRplace, developers will be encouraged to work in the following lanes this time around:

• Patient: Create, update and search patients 
• Terminology Services Track: expand valuesets, validate codes and retrieve human readable labels codes.
• Profile & Validation: Create a profile and an instance; ask a FHIR server to validate the instance 
• "SMART on FHIR" track: Extend FHIR servers or build a client to add OAuth2 to the FHIR REST interface
• Imaging: Imaging results using Digital Imaging and Communications in Medicine (DICOM) standard
• API Beginners Track: For those just starting out with FHIR client applications
• Community Track: Presentations of real life experiences with FHIR (schedule for those is found here)

The full program of events for Amsterdam is here.

We are looking forward to following the action and international perspective this week. As always, interoperability benefits greatly from frequent, iterative collaboration and a broad range of players from across the globe.

And stay tuned to this blog for new content on our current FHIR development.

The CQMsolution Story

Dynamic Health IT first began assisting EMR clients with HITECH certification in the summer of 2010.

Known originally in the 2011 Edition (Stage 1) as 170.304 (j) – and now 170.314 (c)(1), (2), and (3) - the requirements for supporting Clinical Quality Measures (CQMs) proved to be a sticking point for many vendors looking to certify.

Some of our clients who had certified under 2011 edition had done so successfully with the application popHealth for CQMs, a product targeted to Ambulatory (EP) providers, under Stage 1. But users had grown frustrated with the implementation process, one that included difficulty importing data, delayed updates for known issues and virtual machines for various Windows versions that were cumbersome to use.

This frustration was compounded by the 2013 government shutdown that lasted two and a half weeks and affected support and continuity for a host of Health IT-related programs. This put another layer of pressure on vendors facing certification deadlines.

When the 2014 edition of certification standards rolled around, popHealth was not yet certified and ultimately would transition to open source. While DHIT has been involved in open source projects at various, the time-sensitive nature of certification pressed the limits of using open source to build and maintain a certified software package.

PopHealth was built with Ruby on Rails and our development team felt we could harness technology more familiar to our clients (C#, MSSQL) to tackle CQMs. In CQMs, we saw an opportunity to challenge ourselves and embark on some cutting-edge development. We decided to jump in head first and build an what would come to be named CQMsolution.

Our goal from the outset was to create a browser based C# application to support the 93 CQMs (both Inpatient and Ambulatory). We would have to do it from scratch, but we had the development experience and potential clients looking for a new approach.

CQMs don’t allow for a “set it and forget it” approach, so our work did not end with initial development and launch of CQMsolution.

In contrast to the pitfalls of version stagnation that can sometimes occur in open source projects, CQMsolution is subject to an actively managed development cycle. Our team seeks to stay current on updates to Federal policy and quality measure updates across programs (MU, PQRS, IQR). We attend biweekly Tech Talks with Cypress to ensure our software validates with the very latest version of eCQMs and we engage in frequent testing, assisted by an ONC-sponsored tool called BONNIE (a web-based tool primarily for measure developers that allows users to load in quality measures and create test patients).

Where there have been challenges configuring and deploying homebrew CQM aggregators in multi-entity settings, we have worked to ensure that CQMsolution sits atop a stable back-end that runs with minimal client intervention and can be centrally-configured for multiple practices.

Our latest version of the application, which works with Cypress CQM validation software (v2.6.1), includes enhanced drill-down screens and the fruits of a testing process that has increased our coverage of many "border" cases. With BONNIE, Dynamic Health IT has now generated or shared in over a thousand patients to stress-test our application.

These efforts keep CQMsolution current for our clients and on pace with EHR certification and standards.

All of this is not to say that open source does not have its virtues. It most certainly does and often leads to breakthroughs in our industry. Many of us use or even contribute to open source applications on a daily basis. But there can be important differences, especially when dealing in subject matter that is time sensitive (CQMs, check) and frequently changing (double check).

Quality measure software must be updated regularly to accommodate both Cypress validation and CMS measure releases. Meaningful support also should be responsive to client submission deadlines and other potential needs related to reporting and displaying quality measures.

As always, let form follow function.

Stay tuned for a full breakdown of 2015 Certification Updates.

FHIR Connectathon 10: Atlanta

The DHIT team made the trip to Atlanta last weekend for FHIR Connectathon 10. As the Connectathon series moves into double digits, there is a sense of building momentum in the project. The knowledge base for this diverse group of participants continues to grow with each event.

A quick review: FHIR is a set of clinical interoperability resources based on common web standards, including XML and JSON, with a RESTful protocol in which each FHIR resource has knowable URL. FHIR aims to provide the tools necessary for interoperability with enough flexibility to adapt to a wide variety of use cases.

Connectathon 10 took place October 3-4 and featured 6 themes (or tracks) around which real-world scenarios were built for participants to implement against a FHIR server:

1. Basic patient management
2. Terminology Services
3.  Financial Resources
4.  EHR record lifecycle architecture
5. Structured Data Capture
6. Scheduling

The tracking allowed participants to collaborate more easily by identifying finding complementary skills and experience. DHIT’s involvement centered on themes 1, 2, 4 and 6.

Theme 1, which deals with basic patient search and management, is designed for those new to FHIR. Theme 2 involves terminology services and is slightly more advanced, consisting of searching value sets, validating codes against a value set such as LOINC, SNOMED CT, or a FHIR value set. Theme 4 is EHR record lifecycle architecture. This theme is dedicated to auditing lifecycle events such as Patient Create or Update, Appointment Create, etc. Theme 6 concerns the scheduling of appointments using the FHIR protocol: available “slots” can be created for appointments to fill.

The DHIT team’s overarching goal during the Connectathon was to make Clinical Quality Measures (CQMs) work with FHIR. We laid the groundwork for CQM calculation by matching the HL7 Health Quality Measures Format (HQMF) templates to FHIR resources. The FHIR server was then used to populate patient demographics data, encounters and procedures.

In our CQMsolution software, we created a quality measure report using a patient search against the FHIR server to grab the necessary patient data. To retrieve the necessary codes used by the measures, we performed a validation before measure calculation for sections retrieved on each patient. After code validation passed, the calculation was completed and the results were displayed on screen. 

The FHIR mantra: button spotted at Connectathon 10
in Atlanta, GA

One of the primary benefits – and most enjoyable aspects – of a FHIR Connectathon is the opportunity for vendors to meet and test out connections among themselves. Each new touchpoint is an opportunity to break new ground in interoperability. The Connectathon environment creates a multiplier effect as these connections take place, through the testing of code and sharing of ideas.

DHIT has the chance to team up with several groups, including collaboration on patient search with Cerner and appointments with Mirth. We also had the chance to meet and discuss future development goals with leading ‘FHIR Chiefs’ Graham Grieve, David Haye and Ewout Kramer. Our discussion focused on the evolution of FHIR servers to facilitate efficient CQM calculation.

By providing this chance to share ideas with FHIR leadership and solve problems collaboratively with other implementers, FHIR Connectathons capture the spirit of interoperability as well as any event today.

We look forward to expanding the role of FHIR in our product development.  

Keeping Your IIS Site Online

If you are hosting a site with Microsoft Internet Information Services (IIS) 7.0, you should be aware of a potential bug that could take your site offline.

IIS may not always get along with your antivirus updates. DHIT recently encountered an issue in which a McAfee antivirus update causes a key DLL to stop loading and IIS Application Pool to stop, which consequently disables website hosting. When attempting to load an IIS-administered site, you will see a  503 error (Service Unavailable):

Error caused by IIS issue

The particular issue may arise if a component of your antivirus software is removed or expired. For example, your McAfee Host Intrusion Prevention client could be inadvertently updated without all necessary components, uninstalled or otherwise corrupted.

The fix for this issue is quick (and relatively painless), involving a few edits to the applicationHost configuration file.

There are other, related IIS issues detailed in Microsoft support documentation here.

While the fix for this bug straightforward, catching these issues in a timely manner may not be. DHIT uses Microsoft Internet Information Services in a variety of implementations for our applications and has experience ensuring hosting stability.

We recommend not only staying current on Windows and antivirus software updates, but also maintaining a level of support to ensure that potential issues are monitored and remedied quickly to minimize downtime and vulnerability.

DHIT offers tiers of support to accommodate not only ongoing software customization but server continuity. Please contact us with any questions about this issue and keep your health data environment running smoothly.  

Unclogging Data in Health IT

There has been much controversy in the Health IT world over the issue of “data blocking” – to what extent it truly exists and, if so, what to do about it.

It’s worth noting first that the magnitude of this problem may be exaggerated. As recently reported by ONC, an analysis of a nationwide survey of hospitals showed some heartening results:

(N)ear universal adoption of EHRs by hospitals and significant increases in hospitals’ electronically exchanging health information with outside providers compared to past years.In addition, there are a number of technologies available – including DIRECT protocol – that are widely available, easy to implement, but simply underused.

However, even if the extent to which systems are actively obstructing the flow is overblown, there is much work to be done. In testimony before the Senate’s HELP Committee on the subject of health IT “data blocking,” Dr. David C Kendrick – who leads MyHealth Access Network (a non‐profit health information exchange organization in Oklahoma) – provided some helpful guideposts.

Dr. Kendrick first gave a succinct and workable definition of interoperability, in which patients “have their complete, longitudinal medical record available wherever and whenever decisions are made about their health.”

Dr. David C. Kendrick offers testimony before
Senate HELP Committee on Thursday, July 23, 2015.

Kendrick went on to list drivers of data obstruction culled from his experience. Some specific examples include:

• Excessive interface and maintenance costs 
• “Hotel California” problem: vendors do not offer data portability as intended by ONC, so customers “can check out other EHR products any time they like, but their data can never leave” 
• "Garbage in Garbage Out”: Poor data quality and standardization
• EHR-centered development that extends interoperability only to EHR+its partners
• Vendors achieving certification with one feature set, but features are not fully delivered post-certification

In one of the most striking moments in the testimony, Kendrick declared that MyHealth has “never seen a completely correct Patient Care Summary despite processing millions of them.” 

Where data blocking persists, incentives are lacking for collaboration. In Kendrick’s experience, provider-based blocking was a challenge early in the existence of MyHealth, but the problem has “quickly receded as value‐based payment models take hold.” “Data blocking,” on the whole, may simply be a more loaded term for the obstacles that exist in pursuit of the Holy Grail of interoperability.

It’s not easy developing a universal secondary language for health care. But it is up to health IT developers not to settle for “just good enough to pass." As an industry, we now know the ideal to which we are striving and the major barriers.

And while software developers are not policymakers, we can offer our own set of incentives for interoperability through ease of use, affordability and functionality that goes beyond mere compliance.  A good place to start is putting data-sharing front-and-center in our applications.

Interface engines: fueling interoperability

Interface engines are largely hidden to healthcare practitioners, but they can be vital to the exchange of healthcare data. Among the benefits of a good HL7 engine is its ability to function as a nerve center, overseeing all the pathways your data is taking.

When a hospital interfaces with an imaging provider, for instance, it needs to be able to handle multimedia data and integrate it into a variety of workflows.

A recent successful HL7 go-live with Radiology and Imaging, Inc. (Springfield, MA) was a reminder of the essential role an interface engine plays in the effort to achieve interoperability. And since there is no such thing as a plug-and-play interface, an HL7 go-live inevitably requires fully-customized Visual Basic Scripting (VBS). Each project has its unique contours that can be addressed through VB scripts.

In our work with RII, scripting included:

• Automated email notification of team members when a message is fails or is missing expected elements
• Custom routing and filters to match each facility precisely to the HL7 messages and fields it specifies
• Making use of crosswalk tables to translate codes across different systems

On this project, we handled a full menu of data types, including orders via Computerized Physician Order Entry (CPOE), lab results and routing of data to an HIE. Iterative testing and customization was required, to go along with constant sharing of expertise. Detailed but parsimonious scripts were put in place to handle the range of client use cases and continued testing took place to identify and account for these scenarios.

No use case is too trivial to ignore as we jump over the testing hurdles needed to move into production.

After successful testing and launch, we also complete a detailed schematic in Visio. Once it all hangs together – and we can navigate test scenarios to the finish line every time  –the interface will stand up to a production environment.

✦✦✦

Bringing all of your interfaces under the sway of an engine cuts down immensely on system complexity. DHIT is the exclusive North American partner for the HL7Connect engine, which enables us to take advantage of a number of key features to reduce our clients’ interface headaches:

• Reconciliation of HL7 formats from various sending/receiving modules 
• Simple browser-based screens for interface management
• Handling of TCP/IP, web services, FTP and file-based protocols 
• Conversion between HL7 and other data formats
• Storage of data in SQL DB, with message editor that allows for viewing, downloading, tabulation and re-transmission of messages

See our HL7 Solutions for more information.

Direct Protocol and Interoperability: A good report card

Believe it or not, interoperability is happening. You just have to know where to look.

A recent post by John Halamka, Chief Information Officer of Beth Israel Deaconess Medical Center and Professor Harvard Medical School, lays out some concrete ways in which interoperability is taking shape - in large volumes, to boot. While there plenty of barriers still to surmount, the sweeping pronouncements about systems "not talking to each other" and interoperability efforts needing a complete reboot simply do not match reality.

The problem is often that specifics are lacking in the national discussion about patient data. We've
discussed on this blog the ways in defining success for interoperability can be poorly defined - lacking a connection to outcomes for patients and providers. But the same is true of failure, when we talk about how a complete lack of progress is projected onto the health IT field.

One antidote is to look at implementation of Direct Protocol. Plenty of successful case studies are out there. As Dr. Halamka describes it, Direct has provided "a foundation for health information exchange across the country." Both in state Health Information Exchanges and more locally within provider networks of various sizes, Direct is moving health data - both in service of current Meaningful Use goals and in ways that can allow for broader interoperability in the future.

Halamka raises a great point about the necessity of returning to specifics when dealing with Big Ideas like interoperability. It's easy to get frustrated with a national conversation that can be shifting, directionless and sometimes wildly inaccurate.

We should first tee up the problem and see how a technology like Direct can make solid contact. If inability to access a central hub of patient data is one way of framing the issue, then state health information exchange (HIE) success can be used as a yardstick. Combining disparate data from a patchwork of health systems is a mandate for HIEs and the data snapshot Halamka shares on Massachusetts is a highly encouraging report card for the use of Direct protocol in this process.

Progress in interoperability may be halting. But through numerous projects, we've witnessed firsthand the leaps our industry has taken.

Dynamic Health IT has worked in close partnership with MaxMD to facilitate the exchange of clinical documents across a variety of healthcare settings using Direct Protocol. With MaxMD as our HISP, we have brought Direct implementations to thousands of providers.

The capacity to use Direct protocol is required functionality for 2014 Edition certified EHR solutions. Like interoperability success stories, however, it may be hiding in plain sight. Many EHR implementations have untapped potential in Direct to ease the process of potentially challenging data exchanges like Transition of Care. If your software is 2014 Edition certified, it could be as simple as getting a conversation started about a tool that's already under the hood.

Interoperability in Action Post #2: A Tale of Two Connectathons

HL7 International held Connectathon 9 in Paris on May 10 and followed up with a FHIR Clinician

Connect-a-thon on May 15. Both events came at the challenge of interoperability from different angles.

Credit: Yann Caradec

Connectathon 9 had 4 separate themes:

·         Basic patient management

·         Version 2 mapping to FHIR messages

·         Financial Resources

·         Terminology Services

Clinician Connect-a-thon, meanwhile, featured two streams:

·         A “Clinician challenge stream” that tackled the “clinical adequacy, validity, accuracy and reliability of the FHIR clinical resources,” using different test scenarios

·         Testing of FHIR clinical resources through the following environment: http://clinfhir.com/

There were plenty of threads to pick up in the discussion around these events. One of the most interesting was a comment from Grahame Grieve (the ‘man of FHIR’), as captured on the FHIRplace blog:

The FHIR registry is on top of my most-important, damn-if-I-don’t task list.

Users of FHIR need to know if profiles and extensions exist already for the standard to be truly interoperable. It will be fascinating to see how this unfolds – including where this registry (or registries) ultimately lives and who will be its overseer.

Real-world scenarios

A registry is vitally important to the standardization of FHIR, but so is the real-world clinical perspective.

In an effort to ground FHIR testing in real-world clinical scenarios, Clinical Connectathon participants worked from clinical storyboards and scripts. These scenarios were provided in plain-language prose and rooted in common occurrences – through a range of clinical settings – that would make demands on FHIR resources or databases.

These storyboards are highly instructive, serving as a window into how interoperability might play out practically through the use of FHIR and also a more generally instructive testing tool. As we test interoperability in our development work, DHIT strives to simulate common use cases that affect patients and physicians. Particularly relevant to our recent work is the immunization storyboard.

The more we can return to the question of “What do physicians and patients need from this technology?” the closer we get to meaningful interoperability. As the Connectathon demonstrates, we should bake this right into our design and testing.

Extensibility in action

FHIR’s extensibility, at least in theory, allows it to accommodate a wide variety of real-world clinical situations. David Hay, part of the Connectaton planning team, writes over at the ‘Hay on FHIR’ blog: “FHIR has a built-in extension mechanism that allows specific implementations to add the properties they need that are missing from the resources.”

The Registry is the killer app to make these connections. When FHIR knows what to look for, it can rapidly address the demands the clinical world can make on data at rest.

Interoperability in Action Post #1: Immunization Records

Interoperability is a mammoth, catchall topic on the minds of healthcare IT stakeholders everywhere. For most providers, however, the term remains an abstraction. For patients, it likely has little meaning. What matters for both is not some lofty ideal of “interoperability,” but rather improved health and health care experience.

What does interoperability look like when it works to assist providers to better serve their patients? In this series of posts, Dynamic Health IT will look at a few concrete examples of breaking down barriers to health information exchange. Like any physical engineering project, many parts of it are far-from-glamorous. But doing the grunt work is essential to inching closer to fully portable, patient-centered health data.

Making immunization records accessible
Immunization records are historically one of those essential pieces of health information that patients and caregivers have had difficulty tracking down and toting around to each new provider. Providers, meanwhile, often lack assurances that they are seeing a reliable immunization history. The idea behind connecting providers to state immunization registries is to make sure patients receive needed immunizations in a timely manner, removing the headaches of scattered records.

Credit: NIH

In practice, each state has different data exchange needs and policies. Providers – often small private practices – must work with EHRs or practice management companies to navigate the requirements. For the last year, Dynamic Health IT has been increasingly involved in applying our knowledge of HL7 data, information exchange methods and development to bridge this gap.

In Texas, we worked to establish an HL7 interface and secure FTP connection to the state. Through iterative testing, we then adjusted EHR output from the client system to fit state HL7 requirements.

This test case then came to serve as the template for future implementations. Drawing on experience with HL7 interface design and knowledge of other state specifications, we have worked to create a “master message” generated by the EHR. Fields that are optional in some states will be ignored, while in other cases our HL7 interfaces will make tweaks so that these messages will pass testing and be submitted efficiently through any transport method.

In Georgia – whose immunization registry bears the clever acronym “GRITS” – we wrote a web service to pick up immunization messages dropped from an HL7 interface into folders. The web service knows the client credentials and expectations from the Web Service Definition Language (WSDL) on the GRITs site. The two sides talk to each other broker the exchange of information, with our web service pulling down acknowledgments of received messages.

We’re working to ensure that any physician or patient can reach immunization data where and when they need it. More patients have access to an easily-accessible clearinghouse of data reachable from anywhere on the internet. Similarly, physicians are gaining access to more complete patient immunization histories (where appropriate and in keeping with norms of patient consent). It’s an ambitious goal, but we look forward to staying in the trenches.