The surprise announcement at HIMSS 2013 was the CommonWell Health Alliance, a group of healthcare organizations seeking to define and promote a national infrastructure with common standards and policies. The coalition's aim is to build interoperability into its software so that providers can work seamlessly within their existing workflow.

CommonWell consists of 14 members, including the 7 founding members. Membership represents acute and ambulatory care EHR suppliers, as well as laboratory, retail pharmacy, perinatal care, and long-term-care health IT systems. The service initially was launched at more than 12 provider sites in four locations: Chicago, Ill.; Elkin and Henderson, N.C.; and Columbia, S.C.

In November, CommonWell announced the transition from initial launch to nationwide expansion of its services. At the time of the announcement, Athenahealth, Cerner, CPSI, Greenway Health, and McKesson had signed member service agreements with CommonWell in order to offer its services to their clients nationwide. RelayHealth, the service provider and technology foundation that CommonWell uses to provide its services, is a subsidiary of McKesson Technology Solutions.

I interviewed Peter Bernhardt, director of product development for RelayHealth. Before joining RelayHealth in 2006, Bernhardt held various IT positions at a number of companies. He has a BA in economics from Gustavus Adolphus College and an MFA from Columbia University.

Mark Braunstein: Peter, you've been involved since the beginning of CommonWell, so what can you tell us about its founding?

Peter Bernhardt: The first meetings for what eventually became CommonWell were held in the summer of 2012 between Cerner and RelayHealth. Our reason for coming together was and remains to solve a chronic problem in healthcare data interoperability -- specifically, patient identification and record location. When former ONC Director Dr. Farzad Mostashari said government would not solve for a national identifier, we knew the market had to lead and we set out to build what we viewed as "the plumbing" of national healthcare data exchange.

[Does your organization really need around-the-clock access to every piece of information? Read The Cost Of Healthcare Data Access.]

These pipes would allow an endpoint to query for and retrieve data on a specific patient when a clinician needed it, and they needed to be scalable, reliable, secure, and fast. We knew that existing approaches to this problem were difficult to implement and scale. And so, as our meetings progressed and others joined the conversation, we developed our plan for building what are now in production as our core services.

MB: Can you please briefly describe the core services that RelayHealth provides to CommonWell member companies?

PB: The primary services we provide for CommonWell are:

These are the basics for exchanging data across care settings. We just make it easier for HIT systems to locate where the data exists and facilitate the actual exchange as efficiently as possible.

MB: What is the technology infrastructure behind these services?

PB: To take advantage of our members' existing technology investments, we implemented the IHE Profiles for Patient Identifier Cross-References (PIX) to populate our patient index, and our brokered document query and retrieve services are built on the IHE XDS/XCA profiles. Finding where patient data lives across disparate settings of care has to be fast and reliable, and we decided the best way to do this was to centralize these services -- so a user of a CommonWell-enabled EHR would only need to make one query to find out where a patient has data. But our system is able to give them an answer fast, much faster than if you had to make multiple queries across different HIEs or other communities. We also wanted to have functionality that allowed systems to link patient records easily and authoritatively. So for patient location and linking, we built REST services that were inspired by an early draft of the HL7 FHIR specification.

MB: Anyone who follows me knows I'm a fan of Fast Healthcare Interoperability Resources (FHIR). I was surprised to learn that CommonWell adopted it from the beginning, long before it had much visibility. How did that happen?

PB: It was a calculated risk, certainly. Given that vendors are experienced with IHE interoperability and SOAP-based Web services, we talked a lot about extending those approaches to build our services. That's where we started. We were designing services that had to be fast and reliable and easy to use. We spent a lot of time up-front thinking about how we could meet all these objectives: Be standards-based, use existing vendor infrastructure, and build foundational services that would scale and be reliable -- and as fast as possible. REST also factored into the equation. As technologists, we felt that REST will be the architectural foundation for the next generation of healthcare IT products. And then we saw what the HL7 team led by Grahame Grieve were up to with FHIR, and so this was both a confirmation of our own thinking about the future of healthcare IT and an opportunity to prove out an early version of FHIR in a production system.

MB: At present, as I understand it, FHIR is used by CommonWell for administrative purposes such as maintaining your master patient index. In that role it provides a Web services alternative to other messaging standards. Can you tell us more about that and how might we see it used for accessing discrete clinical data elements in the future?

PB: In addition to the "traditional" v2 version of PIX, we also have a REST API for patient management, and that's based on an early version of the FHIR Patient resource. So, instead of sending an ADT message to our PIX manager, a system can add or update a patient in our system using REST. We have vendors using both the v2 PIX and REST to send us their patient demographic data.

As I said before, we also support SOAP-based document exchange, but FHIR also provides resources (DocumentReference) to execute the same transaction using REST. IHE is working on a new version of its Mobile Health Documents (MHD) profile that will be based on FHIR. In fact, we are in the development phase of delivering REST-based document query and retrieve services based on the MHD profile.

As for discrete data access, this is really where FHIR and a REST-based service can shine. Imagine a doctor in an encounter wanting to know a patient's immunization history. Right now, using traditional document-based data exchange, she would have to scour through one or more CCDs to find the information she's looking for. But with FHIR, the doctor could ask only for immunizations, and she can be specific about the immunizations of interest.

MB: Does CommonWell have a formal position on the recent JASON report and the implementation plan put forward even more recently by the JASON Task Force convened by CMS and ONC?

PB: Yes, CommonWell does have a formal position and you can view it on the CommonWell blog. I think this has sparked a lot of interest in the industry for FHIR as the data exchange standard of the future. This enables real meaningful change in how healthcare data can be used to provide higher quality of care, and with things like the SMART on FHIR project I see this as the beginning of creating a rich ecosystem of healthcare applications.

MB: Looking into your crystal ball, how do you see the future of CommonWell and interoperability in general here in the US?

PB: In terms of technology and standards adoption, we've already seen strong interest in FHIR as the new standard for interoperability -- particularly from vendors who are just getting started down this road. I think the future of interoperability lies in being able to target individual pieces of data about a patient. Given what we've already done with CommonWell, helping facilitate discrete data exchange is a natural extension to what we've already built. How fast we get to discrete data exchange will be determined by the major EHR players. Providing secure public FHIR interfaces will be one of the ultimate measures of their commitment to genuine interoperability.

Apply now for the 2015 InformationWeek Elite 100, which recognizes the most innovative users of technology to advance a company's business goals. Winners will be recognized at the InformationWeek Conference, April 27-28, 2015, at the Mandalay Bay in Las Vegas. Application period ends Jan. 16, 2015.