¿Puede FHIR Spark soportar el intercambio de información en salud, es decir, la interoperabilidad?
Can FHIR Spark Health Information Exchange, Interoperability?
by Jennifer Bresnick
Health information exchange in the United Sates may suffer from chronic fragmentation, data duplication, misinterpretation, ambiguity, and disunity, but there’s one thing nearly all providers can come together to agree upon: data interoperability could be much, much easier if health IT infrastructures all spoke the same language.
But deciding what language that should be, not to mention implementing it across tens of thousands of systems, has been a lengthy process fraught with difficulty. From vendor mistrust to reluctance from providers to invest even more in their technologies without seeing measurable return, private industry and government organizations alike have stumbled time and again over bumps in the road to truly interoperable data exchange.
Enter FHIR, the Fast Healthcare Interoperability Resources standard from HL7 International that has rekindled hope of a simple, accessible way to use common internet protocols that change the way healthcare views data exchange.
While this wunderkind of the data standards world may not be the magical solution to every health information exchange problem ever identified, it has been lauded as a huge step forward for interoperability by the Office of the National Coordinator, the JASON Taskforce, and private consortiums including the CommonWell Health Alliance, and the Argonaut Project – not to mention experts such as Micky Tripathi, CEO of the Massachusetts eHealth Collaborative and Chair of the eHI Interoperability Workgroup.
“To me, FHIR is currently the best candidate for the next step forward in health information exchange technology,” Tripathi told HealthITAnalytics.com. “We want to move away from where we are now, which is document-based exchange. Right now, interoperability in healthcare is basically just the exchange of Consolidated Clinical Document Architecture (C-CDAs).”
“The exchange of these XML documents has a certain value, because unlike in banking, where I just need raw data, whole documents are really important in clinical care,” he continued. “For banking, you can just tell how many dollars there are, or tell me how many units there are. Give me an account number, and I’m good to go. I don’t need a document. I don’t need as much context around the data in that transaction.”
But in clinical care, context is everything. “If you just send me some lab results or a list of allergies, that’s great,” said Tripathi. “I need those things, but you haven’t told me the story of the patient, and that’s really important for a clinician to understand. Document exchange is important, but so is that data-level exchange. Health information exchange based entirely on C-CDA XML documents doesn’t allow you to access information at a data level as well.”
That’s one place where the healthcare system has stalled, especially when it comes to clinical analytics and liberating big data from confines that limit its usefulness. C-CDAs provide a tidy way to bundle all the patient information required for meaningful use, but even the ONC admits that developing a truly standardized, simplified framework for C-CDA exchange is beyond the capabilities of the EHR Incentive Programs at this time.
In its proposal for updating the 2015 Certified EHR Technology (CEHRT) criteria, the ONC explains that there are two release versions of the C-CDA, and many health IT systems cannot read one or the other. Instead of requiring health IT module vendors to develop a single document that can be read by all systems, 2015 certified products will need to send two separate C-CDAs, one in each version, and vendors are allowed to accomplish the accompanying error tracking and data validation in any manner they choose.
Transmitting duplicate documents may get the job done, but it isn’t really what many stakeholders have in mind when they hear the word “interoperability.” C-CDA data is not easy to extract to use for clinical analytics and taking the next step in population health management, and it’s not something the majority of providers are equipped to do.
“You can get data out of C-CDAs,” Tripathi acknowledges. “My company does a very large business in data warehousing, where we get over 500,000 C-CDA records a month. We parse those and deliver data-level healthcare analytics back to our customers. You can do it. It’s just very inefficient.”
Healthcare must move beyond temporary patches and short-term fixes that enable a certain level of health information exchange, but don’t allow health IT systems access to deeper, richer analytics and integration functionalities. FHIR is one of the protocols that present a new way of thinking about moving clinical information around.
“The next step in health information exchange is what almost every other industry has already started to do, which is developing more open APIs that allow data-level access,” states Tripathi. “These have to be based on internet conventions like the Representational State Transfer (REST), which is a much easier way to exchange information securely between two different entities. You already use it every day.”
“When you order something on Amazon, for example, look at your browser line,” he added. “If you’re logged in and you click on something, what you’ll see is a URL that says “https” and then this huge string of nonsense. That’s a query-retrieve system that’s generated in your browser and sent to Amazon, and then Amazon immediately returns the results securely. That’s essentially a single line command that can be received by all through browser technology, so I don’t need complicated interfaces. I can do it through any internet browser I want.”
“That’s really the next step forward in healthcare. We need to start taking that kind of approach as we think about interoperability instead of building these complicated interfaces that take too much time and too much money.”
But FHIR “isn’t a magic bullet solution,” Tripathi says, and it comes with its own set of challenges that dovetail with the ongoing, contentious debate over EHR usability. Regardless of which protocols are functioning behind the scenes, EHRs and data analytics interfaces must be user-friendly, and must enhance the provider workflow instead of reducing productivity, sapping time, and wasting energy.
FHIR works so well because it is based on the use of discrete data elements, or resources, that are sufficiently standardized. The resources require data to be entered into the system in an expected and specific manner. “FHIR tells people, in fairly specific terms, that if you want this data resource to be interoperable, you’ve got to enter the information in this standardized way,” explains Tripathi. “That means you’re left without a whole lot of options for how the data is entered by the user, but that’s a way of driving standardization.”
Drop-down menus and check boxes are an excellent way to jumpstart data standardization, but these limited input fields have long been the bane of providers complaining about poorly designed EHR interfaces and a complete lack of intuitive design among available products. But that doesn’t mean FHIR is going to make EHR usability worse. Instead, bringing more vendors into the FHIR community and making interoperability a standard feature may drive competition and innovation among the vendor community, which will have to distinguish themselves on something other than their ability to participate in health information exchange.
“Once you have those expectations for a particular set of things you want to do in FHIR, that’s where the EHR vendor comes in and competes with other vendors in terms of usability,” Tripathi believes. “Some may say, ‘Well, I’m going to force the user to enter everything according to a set of pull down menus. And I’m going to lock it all down so that they won’t enter any bad data.’”
“Others might say, ‘I’m going to allow the user some flexibility, and then underneath the covers I’ll do the mapping. I’ll allow a user to enter an ICD-9 code for a problem and then I’ll map it behind the scenes so the user doesn’t have to worry about that.’ The vendors will figure out which is the right balance for the right users, because we have to remember that healthcare is just like any other market when it comes to segmentation.”
“There are a lot of providers who want standardized buttons and drop-down menus. I hear them say, ‘How come my vendor hasn’t locked down the way that I do this so that the data is normalized?’ Others get tremors when they think about an interface that restricts how they enter data, and they want to have a lot of flexibility. I think you’ll see vendors who take different approaches for different types of users, and eventually they’ll develop products that will meet enough expectations and enough needs.”