“Success always has its home in the last mile ”
Connecting the “last mile” is a term often used to describe the activities required to connect Point of Service (POS) Systems – such as hospital information systems (HIS) and community based electronic medical records systems (EMR) – to external regional or provincial applications (e.g., a lab repository, referral system, clinical viewer, etc.). The term makes sense from the perspective of the people who’ve been a part of a multi-year journey to build the external applications but seems to downplay the magnitude of the importance of having people actually use the application.
“Last mile” integrations are a key focus for many organizations, particularly those that want data to flow in to or out of EMRs. Looking across the country, we see two predominant methods for connecting end users to external applications through their POS systems: 1) Direct integration where data is exchanged between the POS application and the external application traditionally using an HL7 messaging or document paradigm. 2) Launching a web site via the POS system, which then allows the end user to interact with the external application via a web browser.
A third method is emerging, which takes advantage of the SMART on FHIR application program interface (API) spec. POS systems that support SMART on FHIR APIs can launch external applications that can securely interact with data in the POS system. SMART on FHIR apps run on the users’ device which allows the apps to take on the form of a Windows desktop app, web browser app, iOS or Android app, etc.
While it’s nice to have so many options, it also increases the complexity of determining which method is best for particular use cases. The following business and technical considerations can be used to guide the decision-making process. We fully expect each one will elicit a “yeah, but…” response from readers because of the interdependencies between POS deployment models, constantly evolving capabilities of IT, and the specific legislative and regulatory requirements they have in mind. We invite anyone with thoughts on these matters to continue the conversation – reach us on Twitter @GevityInc or drop us a line on LinkedIn (we’ll create a LinkedIn blog post making reference to this article so the discussion can continue in the comments).
Billing. If the POS user’s interaction with the external app is a billable activity, then the direct integration method is preferred. The direct method is more conducive to automatically generating invoices and maintaining a record of the data that supports the billing in the POS system.
Saving to the Patient Record. If the end users need to save data to the patient record in the POS system, then the direct integration method is generally required. It’s also important to keep in my that clinicians have several reasons why they may need to save data to the patient record beyond provision of care, such as assessment of care for research or college audits, and evidence of care for legal matters.
Extracting Data from the POS system. If the external application requires data from the POS system, such as patient demographics, lab results, allergies, etc. then either the direct integration method or the SMART on FHIR method are good candidates. If the extracted POS system data needs to be persisted by the external application (e.g., sending patient immunization data into a provincial repository), then direct integration is likely better. If the extracted data only needs to be read by the external application and is not persisted, then a SMART on FHIR app might be what’s needed. SMART on FHIR’s support for detailed scoping and permissions (via OAuth2) could be helpful in this use case as well, giving fine-grained control over exactly what is shared with the external application, or even implementing role-based access control based on who is using the external application.
User Interface. If the owners of the external application want to control the user interface, then a website or SMART on FHIR app is the way to go. With direct integration, the focus is on data exchange; workflow and presentation of the data is generally left to the POS system vendors to define. This is another use case where the OAuth2-based scoping and permissions features of SMART on FHIR come into play: the external application only has to supply the user’s identity to the POS system, and the information made available to the external application will be scoped accordingly. This eliminates the need to implement complex role-based access control logic in the external application, freeing developers to focus on user experience.
POS System Implementation. Of the three methods, enabling the launch of an external website from the POS system is the easiest for vendors, which significantly decreases the time to enable end users’ access to the external application. This method is great for enabling access to web based, predominantly read only, clinical viewers of data held in various EHR repositories.
Frequency of Changes to the External App. Similar to the POS system implementation, changes can be made to an external web site app with little to no impact on the POS system and thus are rolled out relatively instantaneously. Contrast this with direct integration where changing a field or coded value can impact user workflow and application logic, which has a big impact on the POS system and thus takes much more time to analyze, develop, test and roll out changes to POS system users. Changes to a SMART on FHIR app that are compatible with the POS system’s API will have little to no impact to the POS system. The impact to implementation is largely dictated by the model used for deploying SMART on FHIR apps to POS system users.
There are several other factors that impact the best integration method for particular needs and contribute to the “yeah, but…” reactions people may have to the above generalizations. In particular, POS system deployment models (e.g., true multi-tenant cloud-based solution, cloud-based instance virtualization, bricks and mortar implementation, etc.) have a big impact on the time and effort to roll out changes to end users. Other factors such as the prevalence of reusable single sign on and patient context sharing solutions, SMART on FHIR app types (public vs. confidential, browser-based vs mobile app, etc.), and the trust models established between the organizations responsible for the external application and POS system users, also play a big role in selecting the ideal method of integration.
Connecting the “last mile” is never easy and having more integration methods doesn’t make it any less complex. The upside is that system designers can select the integration method that balances time to deployment with requirements for various use cases.