Details of the HIE Software Solution
Master Person Index (MPI)
The HealthUnity MPI™ system is specifically designed for healthcare environments. The system has repeatedly proven itself as highly effective in demanding clinical environments. HealthUnity has deep experience in multiple HIE environments. In our customer’s regions, the MPI systems work seamlessly in the background, and the attention of the HIE stakeholders is appropriately focused on using HIE to improve clinical care instead of worrying about MPI issues. The HealthUnity MPI can be effective as a stand-alone system, but has also been optimized to perform as a core component of an end-to-end HIE solution provided by HealthUnity.
Built and optimized for healthcare
The HealthUnity MPI system has been designed from the beginning by applying our knowledge and experience specifically to the HIE domain. We have developed our MPI by focusing on the needs of stakeholders in healthcare environments, including hospitals, integrated delivery networks, ambulatory practices, payer organizations and patients and their families. Requirements for an MPI in healthcare can be unique and often differ from those associated with record linking problems prevalent in other industries. For example, MPI linking in healthcare in most cases is expected to render virtually zero false positives (i.e. bad matches). False positives can result in the wrong patient data appearing in another patient’s chart, with potentially serious consequences.
The HealthUnity MPI is able to interoperate with other MPIs and health information exchanges (HIEs) through IHE standard transactions such as PIX/PDQ and XCA XCPD. The HealthUnity MPI server is built with the need for flexibility in mind. We accept different versions of HL7 (both standard and non-standard) and transform it into industry standards before using the information for grouping. Internally, we utilize standards (IHE PIX, PDQ etc.) based storage. In order to scale to a HIE level, robust and easy to support MPI tools, and a proven scalable platform are needed.
The HealthUnity MPI can be effective as a stand-alone system, but has also been optimized to perform as a core component of an end-to-end HIE solution provided by HealthUnity. We use configurable rules-based matching. This approach provides predictability even when using probabilistic matches based on incomplete data, and provides the ability to match with increasing certainty as additional data becomes available. The MPI system includes administrative tools that allow for visual inspection of every record relationship in the database, and the ability to identify the rule that affected the grouping of records. In addition, the system provides workflow tools for manual processes such as inspection of cases that are close matches but do not meet an automated threshold for matching. This way, an organization may, at its option, implement services for manual de-duplication and record merging at the HIE level, or can refer cases back to source data providers to provide the manual labor required to investigate cases requiring de-duplication.
For optimal results, our MPI comes with a default configuration of 11 record grouping rules that we have identified as being highly effective in our previous successful MPI implementations. Our solution exploits unique characteristics of different patient demographic fields to yield near zero false positives and still results in very low levels of false negatives, a quality which is critical for patient record linking. We use over 17 demographic fields out of the box for matching.
MPI administrative tool
Patient management activities such as merge, group, regroup, cleanup of patients is provided by our powerful HealthUnity MPI system, which was designed with a focus on stakeholders in healthcare environments, including hospitals, integrated delivery networks (IDNs), ambulatory practices, payer organizations, as well as patients and their families. Requirements for a healthcare MPI can be unique and differ from those associated with record linking problems prevalent in other industries. For example, MPI linking in healthcare is expected to render virtually zero false positives (i.e. bad matches). False positives can result in the wrong patient data appearing in another patient’s chart, with potentially serious consequences. The HealthUnity MPI architecture is ideally suited for deployment in healthcare environments. Specifically, the architecture provides:
- Three tier architecture whereby we separate the database layer from the application server layer. The app server is load balanced, which offers tremendous performance and HA benefits.
- Highly optimized by large scale testing – tested to over 25 million records with good performance.
- Pre-configured matching rules optimized for scalability and performance; multiple parallel rules.
- Pre-configured “ignore list” which allows for common place holder information to be ignored during matching e.g. some hospitals use SSN of 111111111 for meaning no SSN was provided; similarly “baby boy” or “baby girl” may be used as place holders.
- Performance dashboard.
- As part of deployment we also do performance tuning.
Merging patient records across entities
HealthUnity supports two distinct methods to merge patient records across entities. One of them is rule based auto grouping. Another is manual grouping using the MPI administration tool.
As noted above, through experience we have identified 11 rules that have proved to be effective in healthcare environment. These 11 rules come predefined with HealthUnity MPI. However, we can support practically unlimited number of additional rules to suite the requirement and the nature of data in hand. These rules can also be created later as the MPI gets loaded with more data and new matching patterns emerge. We have an option to re-do the grouping and indexing of MPI in offline mode without affecting the availability of the MPI.
Merges and unmerges are done in source systems and those messages are conveyed to the HIE. We support processing of such messages. Human intervention is only required when a false positive is detected and needs to be unmerged. Unmerge can be handled using automated mechanisms as well as manual (tool based) mechanisms. Automated unmerge is done by sending HL7 ADTA37 messages to the MPI system. The HealthUnity MPI comes with an administrative tool, which can be used to merge or unmerge identities manually. All the administrative activities are logged. Identities manually merged or unmerged can only be unmerged or merged respectively using manual methods, and they are otherwise unaffected by the grouping rules.
Generally, HealthUnity prefers any inaccuracies in a patient’s data to be corrected in the source system to ensure that any potential mistakes are brought to a facility’s attention and so the HIE system may remain coordinated with the source of the data. During the test phase and before go-live, we establish a feedback process with each participant for handling such scenarios. However, it is also technically possible to perform manual changes in the MPI system if the preferred approach is not feasible or not appropriate under particular circumstances. The HIE administrator may manually construct a patient update message with the corrected data and submit it into the HIE or alter the MPI database directly.
For an MPI solution to be useful in the US healthcare environment, at the minimum it needs to be compliant to standards such as PIX, PDQ, ATNA, and CT. It is also important to note that while complying with the standards, the solution should also have the capability to adapt to implementation idiosyncrasies arising due to subjective interpretations of the standards. HealthUnity MPI comes with a powerful xml-based pre- and post-substitution tool that enables us to adapt to such differences without the need for going back to the vendor who implemented the system in the first place. This approach has helped us implement MPI solutions more quickly than otherwise possible.
The HealthUnity HIE solution is compatible with NwHIN Exchange standards. Specifically, it supports NwHIN Initiating Gateway and Responding Gateway interfaces for XCA and XCPD.
Record Location Service
The HIE record location service allows for the querying of a master patient index (MPI) in order to locate various nodes that have data about a given patient and then using that index to retrieve the remote documents. This is a standard component of the HealthUnity HIE solution.
Duplicate data sent to the system are detected as duplicates and harmlessly noted. Merges and unmerges are done in source systems and those messages are conveyed to the HIE. We support processing of such messages. Human intervention is only required when a false positive is detected and needs to be unmerged.
The repository server acts as the indexed store for clinical documents. The HealthUnity repository server implements among other things, the HIE repository interfaces. When documents arrive a workflow engine executes the appropriate business processes that ensure the data is appropriately processed, stored and transmitted. Our repository has support for the HealthUnity Web services APIs while simultaneously supporting the XDS.b standard repository API model. The HealthUnity HIE system has a highly sophisticated data ingestion system (called the “Adapter Server”) that is a cornerstone of our architecture. The Adapter Server takes the HL7 and CCDA messages and applies the correct transformations and mappings such that standardized representations of equivalent HL7 and CCDA messages result. This standardized information is then processed by the various services of the HIE such as MPI, registry, repository, etc.
HealthUnity has extensive experience building large health data repositories such as data warehouses. One of our largest deployments is a large IDN Health System where the HealthUnity solution is approaching 100 million clinical documents (such as CCDA) and adding about 6 million new documents per month. The number of interfaces is more than 24. For them we also bulk loaded a few months’ worth of data. The system is designed to support extensibility.
The Registry server is used during record location and follows the IHE registry interfaces.
Data is typically represented using different terminologies and codes in source systems. The terminology server allows for the quick translation of codes and terminologies within the HIE.
The HIE provides discrete documents (such as HL7) as well as consolidated documents (such as CCDA). These documents have coded values, which follow the standards established by the source application. When a target application requires coded values in its format, the terminology server performs terminology mappings.
HealthUnity employs the HDD Access Health Data Dictionary, which is a CTS compliant terminology server for clinical concepts. Apart from supporting standard terminologies, HDD Access also supports local extensions. Since our solution is CTS compliant, if required, we can replace the HDD Access with another terminology service of choice.
Typically IDN based HIE deployments where only one code set is in use or a few small number of code sets are in use do not need terminology services. Statewide HIEs and private HIEs that have disparate systems are good candidates to consider also deploying the terminology server component from HealthUnity.
HealthUnity’s Network manager enables end users to visually design there HIE network. This tool makes the job of managing large HIE exchanges (such as statewide exchanges) much easier. It is built on a standards-based LDAP directory and comes with a Provider Registry, Node Registry and Services Registry. We provide a graphical tool for creating and managing all three components managed by this service.
Consent Management Service
Consent management service allows for the recording of patient’s wishes as it relates to data sharing. This robust, patent-pending design supports several models including opt-in, opt-out as well as directional consents such as publish and receive.
The HealthUnity HIE solution provides a unique, comprehensive, and configurable solution for capturing and managing patient consent. Once consent has been processed for a patient, documentation for this consent can be optionally uploaded to the HIE. In addition, the patient’s most recent consent status will be displayed on the patient summary screen. If a user attempts to access data for a patient who has denied consent, an informational message will be displayed to the user.
HealthUnity has a comprehensive consent management model based on strong foundational principles. One possible deployment model follows what we describe as a “consent to access” model. In this model, without patient consent, data can be loaded to central MPI servers as well as local Edge Servers hosted by individual facilities. When a provider requests access, the patient can either grant access or deny access. This event is captured at the HealthUnity edge device and if consent is granted, data access can proceed.
Consent management is a governance decision that each organization has to make based on relevant state and local laws. Our system is built with the flexibility to support and implement an organization’s governance recommendations. Consent management can be formally analyzed using a four-factor approach as mentioned below.
Our Implementation Approach: An organization will make governance decisions on the consent model that is most appropriate for its needs. The HealthUnity system can be configured to implement the consent policies with relative ease. If desired, we support digital signature pads to record patient consents as administered at the time of the encounter.
Provider: For most use cases (e.g. Clinical Summary at ED, Hospital), patient consent is typically required. We support out-of-the-box a very flexible system for consent management, including options for both opt-in and opt-out, but ultimately fine-tuned to your governance policies. As shown above, consent capture can be done using signature devices, thereby reducing paper consent forms. The digitized signature is automatically captured to the onscreen form.
Actions supported: Consent Grant; Consent Revoke; Consent Deny.
The consent management system allows data access to be prevented for designated classes of patients.
We also support fine-grained consent policy implementations. Some HIE customers require fine-grained consent options while others want to keep it simpler. Examples of the options we provide include:
- Consent to publish only (e.g. publish to PHR only)
- Consent to receive only
- Consent based on receiving party
- Consent based on type of information
The consent management system allows data access to be prevented for designated classes of patients.
We also support “break the glass” (BTG) access control. The BTG privilege can be restricted using our role-based security system. For example, an organization can designate only ED physicians to have BTG privilege. Use of the BTG feature will create audit entries that can be reviewed to ensure compliance with policy.
Data ownership and liability
Each facility’s data is kept in a named SQL server database. Each facility’s audit log is distinctly maintained. The governance rules across HIE exchange is implemented using our flexible consent management system. Anytime data is accessed, a copy of that is kept in the local repository of that facility, creating an audit trail. These are some of the dozens of methods by which we address data stewardship and liability.
Privacy considerations with alerts
Our system is designed with a flexible consent management and privacy management solution. This enables the strict enforcement of patient privacy requirements and governance policies that each organization sets for the HIE. Alerts are also subject to these established policies.
Composite Clinical Summary Service
The following example illustrates how data flows in the HealthUnity HIE exchange: When a user requests a clinical summary, the request is first submitted to the local node at which the user has login privileges. The request is first checked for role based access control (RBAC) and then patient level consent privilege. Assuming those two passes, the local node then performs a record location service workflow. The first part to this is to query the MPI service to get matching records. This provides the set of target nodes to query. The query is then sent to all of the target nodes and gateways. The results from each target node and gateway is then consolidated into a single clinical summary document before being presented to the end user.
The HealthUnity HIE architecture is component-based with a hybrid data storage approach, maintaining federated data control while realizing efficiencies of co-location of data in one or more central secure data center(s). The HealthUnity HIE is differentiated by its architecture and features not available in traditional HIE systems. This architecture is flexible and utilizes metadata management with no fixed data model.
HealthUnity takes great pride in its proprietary solution called the “Composite CCDA™”. It is best illustrated with an anecdote. A large HealthUnity HIE customer wanted to save the time it took for their physicians to go through over 5,000 patient clinical documents (a combination of demographics, medications, lab results, and reports). They turned to the HealthUnity Composite CCDA service for an answer. The C-CCDA service typically takes less than 15 seconds to combine all of these documents and generate a single CCDA thereby saving the physicians a lot of time (in fact, they refused to spend the time to go over 5,000 documents).
Our edge node, in conjunction with the Composite CCDA Service, takes all of the clinical data acquired for a given patient across the longitudinal record and intelligently combines it to create a single CCDA document. This “smart aggregation” process is customizable along several dimensions. Some of the key configurations that can be applied on our “Composite Clinical Summary” include:
- De-duplication of data
- Filters on time frame, including specifying a max # with in a time frame
- Filters on data type to include
- Filters on CCDA sections to include
- Filters on sort order
- Filters on sources (organizational as well as location of care)
Aside from the key configurations listed above, there are various filters such as hide inactive medications, hide “No Known Problems/Allergies/Medications,” etc. which can also be applied on our “Composite CCDA Service.” These configurations can be applied bi-directionally (both inbound and outbound).
In addition, our solution provides a simple Web Service API “GetClinicalSummary” to retrieve the clinical summary of a particular patient by providing a set of mandatory demographic information (such as MRN and/or Name, Date of Birth and Gender) of the patient. Upon submission of the patient demographic data, the clinical summary of the patient will be returned to the caller in either CCDA XML format or HL7 MDM format. The caller may specify the format (at the time of making the call) by which the clinical summary needs to be sent back by the Web Service. It is also be possible for the caller of this method to specify whether the summary should be generated only based on the documents on the local node or to generate the summary based on documents from the network node as well. This method will return a response message to the caller, containing the clinical summary of the matching patient in the requested format.
In case of failure, the API returns an error object with details such as error code, error message and error details.
Additionally, the API creates Audit Trails (AT) as per the IHE ATNA specification. An administrator can view the audit logs for this API using one of our administration tools.
EHR Integration and Composite CCDA
One of the top requested use cases from our customers is an easy way to get to the Composite CCDA from within their EHR. Here is an example of how GE Centricity EHR, a widely popular solution allows for such integration. GE Centricity has a tab on its desktop called the “messaging tab.” From within this tab, an external website can be accessed with context being passed. The GE Centricity EHR calls our Composite CCDA web page by http posting the parameters (patient MRN, user id, session token/certificate, etc.). The HealthUnity HIE solution returns the CCDA and renders it in a human-friendly html format. A similar feature exists in Cerner Millennium called mpages. When a tab is clicked, the mpage calls our Composite CCDA service to pull up the clinical summary.
Provider Access Portal
HealthUnity provides a comprehensive HIE provider portal, which has been successfully deployed at various HIEs including the State of New York and MedStar Health. This portal enables efficient viewing and exchange of integrated clinical information in a virtualized environment. It enables presentation and access to different data elements as defined by user roles and policies, tightly integrate with tracking and auditing components, etc. It covers all required clinical/document/data types. This portal is built on a modern Web layout with the easiest usability of any solution in the market. Furthermore, this solution supports specified single sign on and embedding within several EHR solutions thereby reducing the workflow burden on end-users.
The HealthUnity HIE solution supports Single Sign-On (SSO) within the Provider Portal. The models supported include a) trusted application certificate exchange model b) long-lived session and c) Microsoft Active directory integration. Context passed includes user context, patient context and activity context.
Over 100 features are included with the HIE provider portal solution, including eligibility verification as an optional service. Some of the key features available in HealthUnity’s provider portal solution:
- Each provider organization gets to administer access in a decentralized manner
- Access to various clinical documents using record location
- Consolidated clinical summary access (CCDA) with de-duplication
- Full access to a suite of applications through an iPhone like interface
- Compete profile management including ability to update one’s own profile
- High strength password administration
- Full Web services exposed so additional client tools can be easily delivered (e.g. iPad)
- Searching multiple MPIs
- Easy filter options to get to exact clinical document
- Full secure messaging solution including Direct support
- Single sign on and context management ready
- Full audit log that will reproduce user actions to great degree of accuracy. We capture IP address, user name, role, patient accessed and document accessed. One of the most comprehensive tools for an organization’s compliance team to use.
- Choice of eRx tools, eligibility verification tools, lab and radiology ordering tools. We provide choices because we recognize each organization may have preferred tools it would like to make available via this portal.
- Full electronic referral capability
- Automated clinical summary generation
- Easily configure exacting CCDA generation (filters, sort ordering, presentation etc.)
- Online eligibility checking option
- Online electronic referral capability
- Online Appt. Scheduling across care settings (thru PMS integration where available)
- Online Surgery Scheduling (thru PMS integration where available)
- Full workflow Management including easy configuration to suit local workflow needs
- Online Order Entry (lab, radiology, eRx)
- Secure Clinical Messaging (Physician to Physician, Physician to Patient)
- Integration into existing Practice Management System, EHRs etc.
Secure Messaging Based on DIRECT
The HealthUnity HIE system includes an embedded DIRECT based secure messaging system. The HealthUnity DIRECT solution is comprised of a set of optimally architected modules that together provide a comprehensive yet flexible model for enabling DIRECT messaging at the statewide level. From a technology perspective, the basic approach encompasses the hosted delivery of a core set of services, which includes:
- Provider directory and index
- Certificate authority (CA)
- DIRECT message routing service (acting as Mail Transfer Agent)
- Exchange Server and Outlook Web Access email client
- Auditing and operational tools
Description of the various solution components:
- Microsoft Exchange Email Server: We provide DIRECT email service using Microsoft Exchange as the mail server and Outlook Web Access as the web-based email client
- Certificate authority (CA): We provide a full Certificate authority service as part of our solution. This helps with testing and staging installations. We have included a set of certificates for production. We are also open to work with an external CA provider selected by the customer.
- Messaging Infrastructure Modules
- DIRECT gateway: The DIRECT gateway service is a set of load-balanced servers, which together provide the ability to encrypt and decrypt messages that are DIRECT compliant.
- SMTP relay services: Organizations that have a dedicated SMTP server for email can also participate in the offering. This is one of the unique offerings of the HU solution.
- DIRECT relay services: Organizations that want to act as their own HISP, but use the HU direct service, are also fully capable of being added to the network.
- Firewall Appliances: The firewall appliance is required from the hosting provider. This provides a base level of capability on the security front that is extremely important in order to secure the overall set of services. The following services are required as part of this appliance.
- Virus scanning
- Intrusion detection services
EHR Integration and Adapters
The ability to integrate into existing environments, provide alerts, and notifications to the HIE and then provide answers and predictions to the users is key. In every HIE deployment there is always an integration effort which becomes the first order of effort. To build these care models, each organization will have their own best practices and workflow and thus need the ability to “program” their systems to these specific, unique use cases. Examples of these advanced cases are listed below:
- CMS Hospital Readmissions Penalties (HRRP)
- Medicare PQRI
- Advanced Illness Management for Dual Eligibles
- State Health Insurance Exchange Mandates
- HIPAA 45 CFR Parts 160 and 164 (security and access)
Since each organization is unique, each use case implementation is unique. Previously, core functionality and reporting was achieved by replacing multiple EMR vendors with a single vendor solution, interfacing HIT systems with EMR systems via interface engines, joining or commissioning a public or private HIE, or some combination of these.
HealthUnity Web Services model can be extended for EMRs that can support such technology as one option for EMR integration into provider workflow across different organizations. For EMRs that cannot support Web Services connectivity, we deploy an integration appliance allowing bi-directional communication with the HIE and the ambulatory EMR. We are working with several vendors to provide the best integration possible to HIE data. Using standards-based mechanisms, we can provide the best experience possible for users of EMRs.
- EHR and HIE-integrated user interfaces
- EHR link to HIE data
- Access by Web-based client for those without EHR
- Single Sign-On between HIE client and EHR
- Manual or auto Publish to patient
- Subscription-based publishing to de-identified repository
- Subscription-based publishing of identified adverse lab result reporting, etc.
- Succinct and relevant medication history that gets automatically imported into EHR and that fires drug-to-drug interaction checking
- Succinct and relevant clinical summary that gets automatically imported into EHR chart of the appropriate patient
HealthUnity has its own referral management system as part of our secure messaging module.
We can handle different types of input file formats (text, XML etc.) by converting them to our internal format, which is based on IHE/HL7 standards. Once the data reaches HealthUnity MPI, it can be queried using any of the HealthUnity MPI interfaces, including the .NET library interface, Web services interface, and IHE’s PDQ interface. This will enable different types of applications to utilize the power of your MPI.
Our solution will enable your organization to get data from different systems, including Medicaid systems, Public Health Systems, RxHub model, etc. We have a large number of partners who are building systems that integrate with our solution. We have also pretested adapters to applications from such vendors/products as GE, Cerner, McKesson, Siemens, Microsoft HealthVault, etc.
As information is passed from a provider application to the HIE, the content of the message is inspected by the HealthUnity adapter service for a variety of purposes. The initial behavior of the solution is to perform syntactic validation of the message. Content is evaluated for completeness, meaning that all required fields are populated with data in an appropriate format for the transaction type. Message content is then transformed and standardized. This process ensures that data leveraged by the exchange is in a consistent format and reflects common codes and definitions for the purpose of routing and managing messages. The validated message is automatically processed and routed for most common scenarios. Since BizTalk server has a full content-based routing service, we can leverage it for other content routing as well.
HealthUnity Healthybase (Data Analytics)
The HealthUnity Healthybase™ system has four major modules: the Extract, Transform, and Load (ETL) module; the Data Warehouse module; the Data Mart Module, and the Reports Module. We designed the HeB product on top of the most advanced platform for analytics, Microsoft® SQL Server® 2012. We designed the solution using a modular architecture thereby offering flexibility to use some modules of HeB while replacing other modules. We use SQL Server Integration Services (SSIS) as our ETL infrastructure and SQL Server Relational Database Management System (RDBMS) as our data warehouse. In addition, Healthybase is comprised of SQL Server Analysis Services (SSAS) Tabular and Multidimensional Services for creating Data Marts, and a wealth of reporting tools such as SQL Server Reporting Services (SSRS), Microsoft Excel® PowerPivot, and PowerViewer for reporting.
The DW is the single source of truth for the enterprise. It is not just a snapshot of facts, but a time-linked capture of facts across the organization. Hence, every attempt is made to ensure the sanctity and integrity of data in the DW using SQL Server technologies such as referential integrity, triggers, and constraints. At the same time, performance and storage requirements require additional measures to be taken. A DW requires optimal performance and effective space utilization. Most of the performance and space optimization techniques need to be utilized with a careful study of the case in hand, or else they may be counter effective. For example, indexes increase performance on one hand, but may also decrease the performance or bloat space requirements if there are unnecessary indexes or unnecessarily broad indexes. Using our years of expertise in handling large SQL Server DB’s, we ensure that we apply these techniques with the finesse required.
We expose .NET and Web services APIs in addition to standards-based APIs, specifically the 2010 version (latest) of PIX and PDQ. We work in collaboration with our customers to determine which specific configuration decisions are required. Currently, more than 75 decision points covering everything from consent management, to API matching setup, interfaces, and more, exist. Our repository has support for the HealthUnity Web services APIs while simultaneously supporting the XDS.b standard repository API model.
Care Coordination Services
HealthUnity HIE provides built in features that enable easy and effective care coordination services. It begins with care coordination on the DIRECT messaging infrastructure for human-to-human communication. In addition we provide configurable workflows for referral management between varied providers. Patient list creation feature allows end user to select the subset of patients who they want to specifically coordinate care. The lists can be static or dynamic (e.g. based on a disease state). Additional steps taken are also documented and tracked by this module.
Patient engagement is a key aspect of overall patient health improvement. The HealthUnity Healthysite Personal Health Record system is built from the ground up to be a “non tethered” PHR. It connects to any number of EHRs. It also allows patients to contribute their own data. In addition provider to patient messaging based on direct protocol is built in. For more information please refer to the Healthysite product site here.
Nationwide Health Information Network Integration Based on Healtheway Standards
The HealthUnity Healtheway services product enables HIEs to extend beyond their boundaries to connect with other HIEs using the Healtheway standards. It allows for sharing of data with multiple external HIEs simultaneously. It also allows for pulling data from multiple external HIEs simultaneously. It includes an Enterprise Service bus service, which extends the Healtheway (XCA/XCPD) capabilities. The ESB acts as a control point for managing data sharing between HIEs. It also provides instrumentation and extended audit logging. The logged data can then be exposed to relevant users by way of instrumentation reports such as Usage reports; Availability reports and SLA reports. For more information please refer to the HealthUnity Healtheway product site here.
Results Delivery Services
The HealthUnity Results Delivery Service is a feature of the HealthUnity HIE solution. It allows for any participating entity in the HIE such as labs, radiology groups and ambulatory surgery centers to publish results to the appropriate recipient in the HIE network.
Orphaned Lab Results Automated Recovery Services
Lab results are typically received electronically by providers from independent labs. However, the lab result document often has missing medical record number identifiers, which help with matching the result with the correct electronic chart within the EHR system. This happens in a situation like the following. Patient goes to a provider and a lab order form is generated either using EMR systems such as Centricity or hand written on a requisition form. The lab order has provider’s MRN filled in. The patient then takes the lab order form (paper) to one of the patient service centers operated by the lab (say LabCorp, Quest Diagnostics, etc.), which is unaffiliated with the provider. These Lab centers process the orders and generate results using either their own local MRN or no MRN. The provider’s MRN belonging to the patient is not recorded nor used while generating the lab results. The only reliable information may be demographics info such as name, gender, date of birth, address, etc.
The HealthUnity lab result routing system feature (which is a component service of the HealthUnity HIE), uses its advanced probabilistic matching algorithms to match the “orphaned” lab result such that the correct MRN belonging to the patient at the provider’s EHR system is inserted and the resulting modified lab result message is then forwarded to the EHR. This makes the job of the EHR lab result import module much easier as it can then go ahead with straight forward MRN based record matching. This module is able to extract up to 85% of such orphaned results. The results that are left over are then submitted to a manual review queue that is part of our secure messaging and workflow management system. Using our web based user interface the administrator on the provider side can easily select the correct record to match the lab result to. This has saved thousands of hours of manual labor. In addition it has also saved thousands of repeat tests and wasted appointments (wasting valuable provider and patient time).