Integrating the HIE into the EHR Workflow

Transcription

1 Integrating the HIE into the EHR Workflow HIMSS Health Information Exchange Committee HIE Provider Engagement Workgroup July Healthcare Information and Management Systems Society (HIMSS) 1

2 TABLE OF CONTENTS The State of HIE Development... 3 The Case for Context Integration... 3 The Case for API Integration... 4 Provider Workflow (patient-specific)... 5 Patient Intake... 5 Patient Exam... 6 eprescribing... 6 edelivery... 7 Consult & Provider-Provider Messaging... 7 Provider Workflow (non-patient specific)... 7 Process In-Box (physician s office work queue)... 8 Query HIE... 9 Discussion on Interoperability... 9 API Messaging vs. Traditional Messaging... 9 Acknowledgements HIE Committee Provider Engagement Workgroup HIMSS Staff Healthcare Information and Management Systems Society (HIMSS) 2

3 This white paper is intended for vendors and developers of EHR and HIE software, and for those potential EHR and HIE customers who are gathering criteria for product evaluation. It is focused on ways to make the HIE functionality, which is typically only available through portals, more closely bound to the EHR workflow and functionality. This integration will enable the physician to take advantage of the additional HIE functionality without leaving their familiar EHR context. THE STATE OF HIE DEVELOPMENT Health Information Exchange (HIE) in its most rudimentary form is transaction-based messaging between otherwise unrelated entities. One of the first transactions typically automated is the movement of a laboratory test result from the lab result producer to the provider who requested the test. The HIE can automate the delivery of the result not only as a message to a provider s in-box within their EHR, but also as an actual delivery to the in-bound interface capability for filing of the discrete lab result into the EHR. Most HIE vendors, in an effort to make the HIE appeal to a broader provider audience (especially physicians who may not have an EHR in their office setting), began storing results either centrally or in edge servers and making those results available through portals over the Internet. The portals have subsequently given rise over time to additional functionality that has been added to vendor HIE software offerings like provider-provider messaging, provider-patient messaging, ordering tests, requesting results, creating consult requests, eprescribing, and other functions typically found in EHRs. In fact, some HIE vendors have gone so far as to create (sometimes Meaningful Use certified ) complete EHR product capabilities within their SAAS (software as a service) offerings. The natural endpoint of this parallel functionality development within the HIE vendor community has led to complimentary, but often unwieldy workflows as physicians find the need to move between the EHR context and the HIE Portal context to make use of an HIE s added functionality. This white paper makes the case for two forms of integrating effort which will first make the switch from the EHR to the HIE simpler and more seamless ( context integration ), and in more sophisticated settings, provide the HIE s functionality without the physician ever leaving the context of their EHR ( API Integration ). The Case for Context Integration The argument for integration of HIE into the EHR workflow context is very similar to the argument for the definition and use of common clinical context objects which launched the Clinical Context Object Workgroup 1 (CCOW) in the late 1990s. For CCOW, the objective was to create the specifications for and connectivity to objects which would be common among otherwise dissimilar applications from different vendors which are run in the same hospital or provider entity. These objects like patient identity, provider identity, session identity, and even clinical subject are stored and 1 Clinical Context Object Workgroup (CCOW) is an HL7 Work Group established to define standards that enable the visual integration of otherwise disparate healthcare applications. The objective is to define clinical element key objects such as patient ID, physician ID, clinical subject, etc. that can be passed between applications to allow the receiving application to orient to the context of the sending application when workstation control is passed Healthcare Information and Management Systems Society (HIMSS) 3

4 passed between applications through application programming interfaces (APIs) or other means. This process allows the application receiving control of the user session to immediately move to the appropriate point in the application indicated by the context objects, without the provider having to reinput this information. The basic idea is to save keystrokes and make the two applications appear to be working in concert with each other. Clinical context objectives (CCOs) have had limited success due to limited vendor adoption. In the most simple case, consider a "one-click" link across from the EHR to the HIE, but with context intact enabling the physician working in the context of their EHR seamless access to information stored in the HIE. Using the CCO concept, the EHR would store the relevant information into a set of objects as it is being used. Once the user makes a decision to access the HIE, those objects are current and can deliver the needed information to the HIE so that it appears that the two applications are well coordinated, which, in fact, they are. To provide a simple scenario illustrating the above statement, consider a physician we will call her Dr. Connected who is performing a subjective interview with her patient when the patient references an Emergency Department (ED) visit last month: Dr. Connected clicks on the "view HIE" button in her EHR, and four things happen behind the scenes: o the provider's credentials are automatically transferred from the EHR to the HIE and accepted at the HIE (sometimes referred to as Single Sign-on or SSO ); o the patient context is passed to the HIE; o the clinical context is set (what chart section the physician is in on their EHR when the request is made); and o the EHR window is suspended and the physician is placed into the HIE portal window at the "search current visits" position. From there, a number of secondary functions are possible through the HIE that include visual review of the ED reason for visit and discharge summary. Dr. Connected can discuss the ED outcome with the patient while in the HIE portal window, and then could optionally mark selected documents to be filed into the EHR. o Each marked document would then be triggered for transfer through normal interface messages from the HIE to the EHR using normal push message functionality. The Case for API Integration From the perspective of a very busy physician with a 15-minute or 12-minute visit interval, there is simply not enough time to search an HIE portal for information, or to jump back and forth between the usage context of the HIE portal and the context of their EHR to search for provider addresses, send messages to other providers, receive messages, review test results and so forth. So, the objective of this HIE-into-the-EHR Integration perspective is to find ways in which common APIs can be developed between EHRs and HIEs so that the physician s workflow is not interrupted, but the additional benefits that an HIE can bring are realized without adding to the physician s already time-critical schedules Healthcare Information and Management Systems Society (HIMSS) 4

5 In the following sections we propose HIE functions and workflows which can be enhanced with interoperability APIs to allow the HIE functions to be seemingly performed from within the EHR. In some cases today we are starting to see EHR vendors work with HIE vendors to provide some degree of this interoperability; however, there is no consistent effort in the industry at this time to make this type of interoperability commonplace. Where interoperability is being supplied through APIs, the assumption is that all of the session transitions and functionality are being performed over an HTTPS connection or similar secured circuit. It is also assumed that there is already an established SSO capability 2 allowing the APIs to function with the asserted privilege level of the provider who has been authenticated to their EHR. These Security Assertion Markup Language (SAML) 3 assertions could be pulled directly from the CCOW work previously referenced. PROVIDER WORKFLOW (PATIENT-SPECIFIC) The approach used for this section is to work through a clinician s use of an EHR in their office which is supported by an HIE step-by-step, as they work through a specific patient visit. Patient Intake Gather relevant information from the HIE: This function is likely not a physician-triggered event, but occurs when support staff schedules and gathers information about a patient, or checks a patient in and rooms the patient. The use case is focused toward those HIEs that do not automatically forward all clinical events to the physician (push messaging). If the HIE provides a query/response process, then the functionality described could be accomplished through that function, perhaps even depositing the data directly into the provider s EHR. Otherwise, the idea would be to pre-fetch the patient s summary clinical record (perhaps a CCR or CCD with appropriate style sheet) into cached web pages available through the EHR s portal, and have the information available immediately when the provider wants to look at it. The capability would request things like: Visit history to other providers Medication history based on current data in the HIE s community record Relevant testing / consults Recent care-related documents (perhaps including a CCR or CCD) 2 Single Sign-on (SSO) is a commonly used term for federated access management. While this concept is not new, it is only recently gaining popularity as many unrelated applications, each with its own access authorization process, attempt to interoperate. In a simple implementation, the Active Directory entry for the currently logged user can be queried by the application receiving control, allowing that user to be authenticated. In a more complex situation, such as that encountered when an HIE function running in a portal is passed control from an EHR, a SAML certificate may need to be used which contains attributes needed to both authenticate and authorize the individual. 3 Security Assertion Markup Language (SAML) is an XML-based set of specifications and processing semantics for a certificate artifact that can be used by the receiving party to authenticate and authorize a user based on the embedded assertions of a trusted issuing party; see Healthcare Information and Management Systems Society (HIMSS) 5

6 The request process would be through either an HL7 appointment or registration message, or an API that invokes the pre-defined service of the HIE configured during setup for that physician. Information provided to the HIE through the HL7 message or the API includes the trigger event, the physician, the patient context, and an indicator of the control point (where control is returned to after the service completes). The triggering EHR or practice management system would execute the HL7 message or API during the schedule commit, the registration / check-in process, or during patient rooming. The result content, if it is not loaded directly into the EHR, would need to be cached as portal pages available to the physician through the EHR. Patient Exam One-button switch of focus from the EHR to the HIE portal, and one-button return: If data is prestaged, as noted above, then when an HIE Portal icon or button is clicked in the EHR, the HIE portal becomes the active screen. If pre-staging is not done, then the provider, patient, and EHR focus would be carried over in the API through context objects as described under the Case for Context Integration section above. The HIE Portal would access the appropriate patient data and display without further input from the physician, and the pre-determined initial screen based on the HIE Portal s setup for that physician or practice would be displayed. One significant addition to this capability would be the ability for the provider to mark or select certain documents or reports to be sent to that physician s EHR. Essentially, this capability would involve the physician clicking on certain documents displayed in the portal (e.g., an individual medication, a medication reconciliation, a laboratory report, a list of allergies) which the physician wants to have filed in the local EHR for that patient. The objects selected would be sent via standard interface message at the conclusion of the select process. It should be noted that whatever interface message is used (whether it be HL7 2.x, a HITSP construct, or an IHE specification), it must be developed and tested to assure that it can be properly formed in the HIE and received and stored properly in the EHR. eprescribing Incorporation of eprescribing workflow and functionality into the EHR and HIE: eprescribing generally involves several steps, most of which the EHR probably enables, and part of that enablement may be delivered from third parties such as Surescripts, RelayHealth or Emdeon. These secondary datasets include functions such as eligibility, deductible and co-pay information, formulary (covered meds, recommended generics), and interaction rules triggered from the active medication list. HIEs may provide connectivity to these functions as an alternative to the EHR s secondary data suppliers. Consequently, for each of the eprescribing data-function sets, an API that calls the subject HIE functionality needs to be provided, data can be delivered to the EHR for internal processing, or the entire function can be handed off to the HIE for completion. The context is the provider, patient, insurance/plan, proposed medication (or pointer to the med list), and trigger code (what functionality is being called). Clearly, this capability will depend upon the depth of functionality in the EHR, and one would expect that EHRs will be required to have very specific eprescribing capabilities if they are 2011 Healthcare Information and Management Systems Society (HIMSS) 6

7 certified. The HIE functions that may be of most interest to the providers are those which third party eprescribing vendors may alternatively be provided through the HIE. Control is always automatically returned to the EHR for the end-of-visit patient instruction printing and record keeping. edelivery A sub-component of eprescribing: While most EHRs have eprescribing functionality, the edelivery process is either not addressed, or the way it is addressed is through connection to an eprescribing vendor with limited reach. Often, after prescriptions are created through the electronic record, they are dropped to print or fax. The HIE is likely to have a longer and more thorough reach, but to deliver the Rx (or multiple Rx), the connectivity of the HIE needs to be made available within the context of the EHR. The API would switch to the HIE and bring up addressing of the prescriptions, and then move automatically to transmission. Alternatively, the API could just transfer a list of available pharmacies in the area to the EHR s edelivery capability. The context is the provider, patient, and Rx list (with all data completed). Control is always automatically returned to the EHR for the end-of-visit patient instruction printing and record keeping. Consult & Provider-Provider Messaging Secure messaging between providers: While some EHRs treat consults like an order, others have specialized functionality for creating the consult and even attaching demographic and clinical data needed by the consultant. Within a specific instance of the EHR software, consultants who are part of the IPA or medical group can be addressed directly and sent to directly, and within some EHRs, even those physicians in different EHR instances can be selected and sent to. However, HIEs are typically the more common method used for generalized communication of data between physicians in different entities on different EHR instances, or even different EHRs. This API would operate similarly to the eprescribing / edelivery API noted above specifically, a consult or message can be composed within the context of the EHR and then sent to the HIE for addressing and delivery, or the API can just retrieve the addresses for the provider s consultant list and the consult / message can stay within the context of the EHR. The context is the provider, patient, message, attachments, and message type (consult, referral, simple, clinical, etc.). It is also important to note that the primary function of the Office of the National Coordinator for Health IT s DIRECT Project 4 is to securely send messages and documents directly to a known endpoint. If the EHR has implemented the DIRECT protocols for messaging, this can be an effective substitute for an API that accesses the HIE s participating provider list. PROVIDER WORKFLOW (NON-PATIENT SPECIFIC) Physicians and, more often these days, coordinated care teams have office time designated to handle inbox queues of patient-related messaging subjects such as refill requests, questions relative to a visit 4 See Healthcare Information and Management Systems Society (HIMSS) 7

8 or medication, appointment requests, non-urgent telephone visit requests, and so on. The physician and/or care team needs to be able to process these message queues efficiently and effectively, conserving as much time as possible, which means that workflows for the various kinds of messages should be well coordinated between the EHR and HIE. Process In-Box (physician s office work queue) There are two contexts for the in-box one is that the HIE s version of an in-box is being used by the physician. In this context, most interoperability is provided through messaging within the HIE and between the HIE and the various inter-connected EHRs. It is important to note that in most instances where physicians have a reasonable EHR in-box capability, they will range from disinterested to violently opposed to using the HIE in-box. Physicians are simply not interested in looking in two places for messages, and moreover, every time they must do so, it detracts from their routine and adds precious minutes to their work day. The other context is the more important one it is the physician or the care team member using the EHR s native in-box, which allows messages to be read, responded to, and charted, with research into the EHR and HIE, if needed, taking place in a seamless manner. There are three APIs that appear to make sense in this context: Read Message API: This API allows the HIE s message queue to be processed just as if it were a part of the EHR s message queue. While clearly the most difficult of the three, if done well it would completely relieve the user from concern over which context they were in and allow them to focus on the various care team and physician tasks. The API provided by the HIE would transform (if needed) the provider s message queue into a simple mail message format, with attachments, and would make each message available to the API. When a message is delivered through the API, it would be marked as read, but all services available through the mail services would be available upon the message disposition. Messages read through that protocol would be downloaded into the EHR s message system just as simple messages are transferred from cloud Internet mail servers to client mail systems. Patient data attachments must be handled correctly and there should be some method of acknowledging to the HIE that the message has been read vs. simply delivered. Post Message API: This is the companion API to the Read Message API in that it allows new messages (including new, reply, and forward from existing) to be posted, and uses the combined address lists of the internal mail system and the HIE. All typical mail functionality that one expects from simple servers should be available through this API. Patient data attachments must be handled correctly. Find Recipient API: This special purpose API taps into the HIE s ability to find the address either within the HIE or outside the HIE through search of an external directory service, such as the state-wide ELPD/ILPD directory services. It will be used by physicians looking to refer patients externally to providers who are new to them, or to send information to physicians who may have called in a request for information regarding a traveling patient. The API would 2011 Healthcare Information and Management Systems Society (HIMSS) 8

9 include demographic information on a provider (including NPI), and would search the HIE s directory and/or the state or other directories to find any providers that fit the search criteria. Query HIE The other workflow where care teams will want to search records from both their EHR and the HIE is associated with information on other patients being referred into the provider s office. In this situation, it is expected that physicians will send information about the patient, including reason for the referral and a Continuity of Care Record (CCR) or Continuity of Care Document (CCD). The message may be sent into the care team inbox, but the provider may need more information about the patient than was sent on the referral. This API is not unlike the Patient Exam API, but it anticipates incorporation of the foreign patient identification and expects to actually traverse both the local HIE and a remote HIE. It may also use either or both of the state and the Nationwide Health Information Network (NwHIN) Cross-Community Patient Discovery (XCPD) locator services. DISCUSSION ON INTEROPERABILITY API Messaging vs. Traditional Messaging Health Level 7 (HL7) and most other industry groups have traditionally approached interoperability as an asynchronous transaction messaging function. This approach focuses on defining and creating trigger events inside the EHR or HIE that cause a certain code to execute which, in turn, ends up sending a message (transaction) through the EHR's or HIE s transaction gateway to the destination EHR or HIE. These messages are transmitted generally through the Internet or over virtual private networks using the state- or NwHIN- or destination HIE-defined methods to a destination server, often a File Transfer Protocol (FTP) server or, in more modern settings, a Hypertext Transfer Protocol (HTTPs) listener. In even simpler cases, the transaction is "dropped off" on the local EHR server and picked up through a polling process. This is all asynchronous messaging. In the web-services world, interoperability is often defined as the ability to define services and service interfaces such that by using an API specification, a service can be called in real time a foreign service to the calling application. The calling application through the pre-defined API provides the parameters the service needs, and then hands control to the service to perform its function; if a result is expected, the result is returned either synchronously (through the same bound session), or asynchronously through a new session that the service initiates with the EHR using the service Identification (ID) from the initial session. This service-oriented architecture (SOA) is rapidly gaining favor in the HIE services domain because many point services can be defined and supplied by an HIE to all of its EHR users; these, in turn, add real value to the EHR. The workflow interoperability discussed above is focused on taking advantage of this shift toward SOA to enhance and standardize some of the more common functions provided by an EHR. The working hypothesis is that providers would rather work in the familiar context of their EHR than to have to jump back and forth between the EHR user interface and the HIE user interface Healthcare Information and Management Systems Society (HIMSS) 9

10 In summary, as the healthcare environment in this country is driven by healthcare reform to become more efficient and produce better outcomes, we must become more cognizant of the physician s workflow. Physicians will be supplemented by their care teams, with each person taking on certain defined roles, and with both the physician and the care team relying on the EHR to deliver many services in ever more efficient ways. This paper has explored many such ways in which an EHR can be positioned to interact and collaborate with HIE to make the EHR user s experience both more userfriendly, and more efficient. The inclusion of an organization name, product or service in this publication should not be construed as a HIMSS endorsement of such organization, product or service, nor is the failure to include an organization name, product or service to be construed as disapproval. The views expressed in this white paper are those of the authors and do not necessarily reflect the views of HIMSS Healthcare Information and Management Systems Society (HIMSS) 10

11 ACKNOWLEDGEMENTS HIE Committee Provider Engagement Workgroup This white paper was developed under the auspices of the HIMSS Health Information Exchange Committee. Special acknowledgment and appreciation is extended to David Minch for serving as primary author of this paper. The HIE Committee Provider Engagement Workgroup members who participated in development of the white paper are: Noam Arzt, PhD, FHIMSS HLN Consulting, LLC Kevin Lemire, CPHIMS Medicity David Minch, BS, FHIMSS John Muir Health Vicki Wheatley QuadraMed R. Lenel James, MBA, CPHIT, CPEHR Blue Cross and Blue Shield Association Ginny Meadows McKesson Corporation Joseph Wagner, MPA, FHIMSS TELUS Health Transformation Services HIMSS Staff Pam Matthews, RN, MBA, CPHIMS, FHIMSS Senior Director, Regional Affairs HIMSS 2011 Healthcare Information and Management Systems Society (HIMSS) 11