What Seegnal offers, might, at first glance look simple: Seegnal is a real-time clinical decision support (CDS) platform. A healthcare organization send us patient’s medications, as well as some additional clinical data, and we’ll return information about what might be wrong if that specific patient is prescribed those medications. This is of course a simplistic description, but even at this level, both the “send” and the “data” parts present practical challenges. This is because the electronic health record (EHR) system that should be sending and managing the data is a separate entity, it was  developed by different company, that follows its own standards, and naturally, there are many EHRs, creating a complicated environment to operate in. In other words, interoperability is the name of the game.

In technical terms, the “sending” and the “data” challenges, are API specifications and data format. Seegnal naturally has its own standards for both, as do many other CDS services. The need to adjust to all such custom formats seriously inhibits the ability of a healthcare organization to fully leverage the benefits and the innovation brought by the various CDS applications in a transparent and easy manner. Clearly, there is a need for a universal standard for both API and data format in healthcare IT. Luckily, that is not a new idea.

The standards of clinical data format have been evolving for decades now. The latest one, called FHIR, is gaining popularity fast. As to the API specifications, the emerging standards develop for specific domains of application. In particular for services like CDS, the leading standard is CDS Hooks, developed and gradually adopted by the leading EHR systems in the US. By supporting both FHIR and CDS Hooks, Seegnal offers better and easier interoperability and integration process.

FHIR

The Fast Healthcare Interoperability Resources, or just FHIR, is already, although only several years old, a widely known data format standard. FHIR was developed by the Health Level Seven International (HL7) health-care standards organization specifically to facilitate efficient data exchange between electronic health services. It has been endorsed by various health IT committees and is already supported by the largest EHR systems for many applications. It is an advanced standard, robust and generic, comprised from modular referenceable units called resources. FHIR is compatible with the latest web standards and is built with service-based architecture in mind. Finally, it is being increasingly adopted by a growing ecosystem of enterprises, open source initiatives and more. For Seegnal, the ability to receive and digest clinical data in FHIR format means significantly smoother integration with its customers.

CDS Hooks

Each EHR historically had its own way (if at all) of using third-party services. The need for such uses can vary greatly, but the majority are use cases of various clinical decision support services, that add insights, alerts, monitoring, etc., to the clinical process as a whole. Hence, several large healthcare organizations have joined forces to create guidelines and standards for an easier integration of CDS services with EHRs – CDS Hooks. The CDS Hooks specifications basically suggest that a CDS service, when registered with the EHR, provides a list of callbacks (URLs) to be triggered at specific stages of clinician’s workflow. For example, upon opening a patient’s chart, or placing a medication order. This specification leverages the FHIR standard, as the EHR can now send along with the triggered calls some clinical data in FHIR format requested during registration, or, the CDS service can access the EHR’s FHIR server during its processing of the call – depending on implementation configuration. The callback’s reply has a predefined structure, and can contain suggestions, alerts, messages, etc. It is the EHR‘s responsibility to process them to benefit of the clinician – display, notify or otherwise react, depending on the response properties. The CDS Hooks specifications also include security guidelines, which are yet another important aspect of healthcare IT.

Beyond hooks

The CDS Hooks specifications suit Seegnal almost perfectly. After all, the paragraph above is a general description of our workflow – in part. The thing is, Seegnal’s job is not complete with a simple, real-time response to a triggered CDS hook. In case there are potential drug-related issues, Seegnal provides a web-based UI that not only details the issues, but also lets the clinician effectively simulate several optional scenarios and choose alternatives to the problem-causing medications. In fact, the clinician can use Seegnal UI even in case there are no medication issues (yet) – for example, to see if an added medication or a potential change in the patient’s lab results or conditions might cause a problem. That’s why in our CDS Hooks response, there’s a link directly to Seegnal UI, to be opened automatically or by the clinician, depending on the use case.

But even this is not the end of the story – when the clinicians decide, aided by the Seegnal UI,  what medications they needs to replace or modify, they clearly want these updates to appear in the EHR medication statement, for final approval and prescription, instead of having to retype all medications manually in the EHR. In other words, Seegnal needs to report back to the EHR all the medication changes done by the clinician. Moreover, this should happen asynchronously, meaning, not as a response to a CDS hook triggered by the EHR, but because of the clinician’s actions in Seegnal UI. Although there are several alternatives of doing that, some based on old text-based HL7 standards or proprietary APIs, one of the more efficient ways is to launch the Seegnal UI as a “SMART on FHIR” app.

SMART is another important initiative in the ecosystem, which promotes a free and open set of API specifications, enabling third-party apps to be embedded in the EHR while accessing the required clinical data – you guessed it, in FHIR format – in a uniform, secure and controlled manner.

When fully standardized and adopted,  this will not only alleviate the cumbersome integration development process for each EHR and for every app, but simply put, will enable an app to be developed once, and then being run seamlessly inside many different EHRs. From a different perspective, adoption of SMART makes the EHR itself a platform for interchangeable apps, developed by third-parties. The future is just got a bit brighter…

Resources: FHIR, CDS Hooks, SMART