Healthcare Affected by Providers’ Interoperability using Health Information Exchanges

Abstract

This paper explores how the healthcare industry works with relation to clinical data interoperability between providers and Accountable Care Organizations (ACOs). It examines the methods they use regarding the exchange and offers solutions which have the potential to not only facilitate the procedure, but to open new opportunities that are not possible or easily accessible at this time such as credible regional and national health data for use in public health. This paper also considers and looks into existing and potential clinical and technical issues pre- and post-implementation of the proposed methods and investigates their possible impact on the health care system.

Keywords: interoperability, health information exchange, HIE, ACO, healthcare, public health, population health

Healthcare Affected by Providers’ Interoperability using Health Information Exchanges

Interoperability is needed to provide information when and where required, facilitate quicker and more soundly based decision making, reduce waste by cutting out repeated work and improve safety with fewer errors (Benson & Grieve, 2016). Electronic Medical Records (EMR), Health Information Exchanges (HIE) and patient portals provide valuable methodologies to providers. Most patients in the behavioral healthcare system either experience co-occurring disorders or have other general medicine treatment teams; therefore, it is even more important that interoperability be effectively implemented for this population (Levenson & Mukherjee, 2016). To be successful, population health requires data, both to assure the good coordination of care and to feed the analytics that are so important to understanding what is happening in a population, and being able to manage both quality and utilization, which of course is a proxy for costs (Sutner, 2016). Effective population health management demands open communication and collaboration through interoperability and an ability to have access to a patient’s entire record (Levenson & Mukherjee, 2016). In practice, accountable care needs more than an EMR, it needs a suite of aggregation protocol to provide patients the best care management solutions available. It requires multiple systems to work together; moving beyond interoperability focused solely on the sharing of data and moving toward workflow interoperability – the ability to have multiple systems work together seamlessly. I believe there are three key steps to ensure all interested parties develop successful interoperability – for patients, providers and everyone involved in health care systems.

Share Data.

It is like the pharmaceutical commercials on television – “tell your doctor if you have cancer, HIV, or another disease.” – I suspect most people think “shouldn’t my doctor know that?”. Without the ability to share health data, they may not. What happens if the patient forgets to mention a serious disease? Data interoperability provides benefits to patients in two ways. One is the reduced costs and/or improved quality mentioned earlier, but the second benefit is that the burden is taken off the patient as the aggregator of information.

Change the Data Flow.

The interconnectivity of solutions has led to point-to-point solutions, which is very inefficient. If a population health service organization wants to aggregate data, the aggregation must occur within the solution, and individual compatibilities will most likely have to be built within each EMR. Also, a single upgrade to one peer may need the upgrade of all the peers it is connected to. Health Information Exchanges (HIEs) are supposed to help with this. Although there are somehow successful ones like NEHEN, HIEs in overall haven’t helped the cause for a variety of reasons.

Standardization.

Health data standards are a necessary component for interoperability in health care (Benson & Grieve, 2016). I plan to dig into successful HIEs such as NEHEN and their primary success factors and hopefully compare them to other similar systems. For example, the primary success factor for NEHEN has been the collaboration between health plans and providers. Collaboration has enabled the members to share costs, leverage experience gained by other participants, and accelerate the benefits of administrative simplification. One of the numerous challenges big data analytics is facing is the standardization of data; there is a necessity to achieve full interoperability with such a vast amount of patient data coming from hospitals and other facilities (Marcheschi, 2016). Effective population health management also demands open communication and collaboration through interoperability and an ability to have access to a patient’s entire record. To maintain effective communication and encourage collaboration, which will ultimately improve healthcare outcomes, the system must commit to supporting at least the most commonly and widely used standards as well as converting all facilities to a single system or incorporate an overarching platform that can aggregate information from contrasting systems and blend the data so it can be accessed by multiple providers across all specialties.

 

Interoperability barriers slow providers down

For accountable care organizations, a lack of interoperability between their health information technology systems and those of providers outside their ACO is the No.1 challenge they face, cited by 79% of respondents to a survey of 68 ACOs by group purchaser and performance improvement company Premier and health IT collaborative eHealth Initiative (Conn, 2016).

ACOs are having a tough time integrating data from different clinical sources into their care delivery systems. Medical specialists are less able to share patient records and information than others. Consequently, 69% of the ACO respondents surveyed reported having a harder time integrating specialty-care data, almost double the number for any other care setting (Conn, 2016). Exchanging data between providers require complex data-sharing agreements and new interfaces between systems. ACOs would most like to have greater interoperability with behavioral health and long-term/post-acute care (tied at 67%) (Conn, 2016). Current patient medical information is fragmented across healthcare systems; therefore, standardized health information exchange can integrate patient information and facilitate health care systems to achieve truly patient-centered care. The barrier to interoperability is the lack of standards to make it easy to share information back and forth (Sutner, 2016).

 

Description of Data to be Transmitted

The aim of this paper is to investigate an interoperability framework with the ability of the integration of complete virtual longitudinal records under the healthcare information exchanges (HIEs). Health care processes require the use of data and information and they also produce or create information. Hospitals and other data sources can each potentially provide various types of clinical data including laboratory results; radiology reports and images; other transcribed reports; and admission, discharge, and transfer notifications (ADTs) (Maloney et al., 2014). The quality of care can be significantly enhanced and healthcare cost can be substantially reduced if healthcare providers can timely access patient records that are scattered among electronic based systems.

Accordingly, all data relevant to a patient’s ongoing health and its management in disparate health information systems and the patient’s personal health records (PHRs) are supposed to be considered in the transaction. The electronic health record (EHR) system relies on comprehensive databases, as do other clinical applications (Wager et al., 2013). This paper will mainly focus on key clinical data collected in EHRs, including patient demographic characteristics and general profiles, laboratory and test results, medication lists, problem lists, and visit/discharge summary.

Another important transmitted data in health care system is billing data needed to process reimbursement claims. Generally, the health care organization’s accounting or billing department is responsible for processing claims, an activity that includes verifying insurance coverage, billing third-party payers (private insurance companies, Medicare, or Medicaid), and processing the payments as they are received. The UB-04, CMS-1450 and CMS-1500 are standard billing forms to be submitted to the third-party payer. Also, patients and providers’ identification, visit dates, diagnosis and procedure code and extensive information captured in form.

I chose clinical and billing/claims data via NEHEN, a consortium of regional payers and providers I plan to examine further in the paper, which provided solutions for exchanging these data among their members. More importantly, the data carry major patient information needed to be shared during health care processes and to promote the coordination of care.

Code Systems Identification

Health data consist of heterogeneous information, i.e., clinical findings, lab values, genomic profiles etc. To ensure both the sender and recipient understanding the same data in the same way without ambiguity. The transmitted data need to be represented in a comprehensive and manageable format which is at best represented by the code systems and semantic annotation.

RxNorm.

It is a standard terminology produced by the National Library of Medicine (NLM) that provides a normalized naming system for generic and branded drugs; and a tool for supporting semantic interoperation between drug terminologies and pharmacy knowledge base systems. It is built on and derived from 14 drug vocabularies commonly used in pharmacy management and drug interaction software. As of the calendar year 2010, RxNorm concept unique identifier (RXCUI) are used in the CMS Formulary Reference File (FRF) to represent drug products, replacing proxy NDC codes that were used for the same purpose previously.

SNOMED CT.

Systematized Nomenclature of Medicine — Clinical Terms is a comprehensive multilingual clinical terminology used in electronic health records and interoperability. Its components are concepts (codes), descriptions (terms) and relationships. Concepts are organized into hierarchies. SNOMED CT expressions are either a single concept (precoordinated) or more complex post-coordinated expressions using compositional grammar. Reference sets are used to provide subsets of the whole terminology for specific purposes.

LOINC.

Logical Observation Identifiers Names and Codes, started in 1994 by Regenstrief Institute, Inc., is a community-built universal code system that facilitates the exchange, pooling, and processing of laboratory and other clinical observations. It provides a set of universal names and ID codes for identifying laboratory and clinical test results. LOINC has been widely adopted by over 40,000 users from 170 countries. LOINC has historically been used in conjunction with the Systematized SNOMED with LOINC providing codes for the question and SNOMED providing codes for the answer or value. The Unique code is 3 to 5 digits followed by – and another digit.

ICD-10.

International Classification of Diseases is copyrighted by the World Health Organization (WHO). The ICD-10-CM is a morbidity classification published by the United States for classifying diagnoses and reason for visits in all health care settings. ICD10-CM codes may be from 3 to 7 characters. And the ICD-10-PCS is a procedure classification published by the United States for classifying procedures performed in hospital inpatient health care settings. ICD-10-PCS codes are composed of seven characters. Each character is an axis of classification that specifies information about the procedure performed.

Refer to Table 1 in the tables section, for a more detailed description of main code systems used in the proposed health data interoperability framework.

 

Standards Supporting Data Access and Semantic

The organizations that create or use data exchange standards are either creators of new standards or users of existing standards who modify an interoperability specification for a specific purpose (Oemig et al., 2016). It does not matter who authorizes the work or who performs it. What counts is the outcome.

X12.

It is basically a standard for electronic exchange of business transactions between industries, especially electronic data interchange. As it is related to finance, its widely needed and used by many organizations worldwide. NEHEN as an HIE, is no different in using this standard. Money is the first thing getting attention in every industry, even healthcare. If we follow the money we’ll get all sorts of information in the process, so why not use this as an advantage for data interoperability. Financial data are used in all sections of the health care industry. I.e. Health plans, providers, ACOs, labs, pharmacies, pharmaceuticals, employer groups, government institutions such as CMS, etc. Although public health doesn’t seem to be needing this data, it could benefit from other information that comes with it. It is also one of the oldest financial standards and it’s not being used only in the health care industry. There’s hardly an alternative to it, and even if there is, it’s either not suitable for health-related data or it’s not that well known. It could be called the most famous and widely used standard in health care finance. NEHEN provides secure transport and routing of these broad category of industry-standard transactions – all HIPAA-mandated transaction exchanges including the 270/271, 276/277, 278, 837, 835, 997, 277ACK (Nehen.org).

Health Level 7 (HL7) V2.

It is the workhorse of electronic data exchange in the clinical domain and arguably the most widely implemented standard for healthcare in the world. As mentioned before, when you have an old working standard that has roots everywhere, it’s darn hard to replace it with something very different and new. 95% of US healthcare organizations use HL7 V2 and more than 35 countries have HL7 V2 implementations (HL7.org). Although it is not as old as X12, it’s old enough to win the battle versus V3, which is the newer supposedly better version of it. There are patients, providers and ACOs which need the exchange of clinical data. But the clarity of which data should be transferred and who has access to which part, is still a struggle. Compared to financial data, there are less laws and regulations on who should have access to the data and who can store and delete it. Some may argue that patients are the owners of their EHRs, yet most providers claim ownership of the data and they may have the right to do so. The term “Data Owners” refers to both the data sources that generate clinical data and the corresponding patients (Maloney et al., 2014).

HL7 is often called the “non-standard standard”. It may not be fair, but it does express the fact that almost every provider is special as they can have their own local special messaging. This makes the interchange a problem as different providers won’t know how to interpret the information they received from other providers. Both the sender and recipient need to understand the same data in the same way (Benson & Grieve, 2016). Even if they receive data which they understand, there’s the debate of whether the data is reliable and if they should store or even use that information. The IEEE definition explicitly refers to two aspects: first of all, information must be exchanged, which refers to the functional/syntactical characteristic; but the more important part is the correct semantic interpretation allowing for use of the exchanged information (Oemig et al., 2016). HL7 helps with the semantics and is supported by NEHEN, including clinical summary (CDA R2 CCD), lab results, immunizations, and syndromic surveillance.

Fast Healthcare Interoperability Resources (FHIR).

It is a next generation standard for exchanging healthcare information digitally in response to limitations in HL7 V2 and V3. It is the most important new health interoperability standard for a generation (Benson & Grieve, 2016). It represents clinical data as resources, where each resource is a coherent expression of meaning stated in terms of well-defined fields and data types. FHIR’s clinical resource definitions are concrete, intuitive concepts such as Medication Prescription, Adverse Reaction, Procedure, and Condition. These resources constitute a graph of clinical data by explicit inter-resource references. For example, a Medication Prescription resource explicitly references its prescriber (a FHIR Practitioner), its patient (a FHIR Patient), and the drug prescribed (a FHIR Medication).

FHIR aims to simplify implementation without sacrificing information integrity. It uses XML or JavaScript Object Notation (JSON) to encode messages and defines a common interface FHIR RESTful API for medical software interoperability (Kasthurirathne et al., 2015). Representational state transfer (RESTful) Web services are an approach of providing interoperability between computer systems on the Internet. REST-compliant Web services allow requesting systems to access and manipulate textual representations of Web resources using a uniform and predefined set of stateless operations. RESTful API have been implemented by many big companies such as Google, Apple and Facebook. They have shown that it is possible to build large integration- based ecosystems quickly, that developers can easily integrate with RESTful services, and that these services scale very well in a technical sense. FHIR specification is broader and looser than normal RESTful APIs as it is a general specification for exchanging data between multiple healthcare parties. The FHIR RESTful API consists of system Service, type Service, instance Service, operations, and version tracking. It provides a record-centric approach to data exchange. Instead of asking the server to perform some operation, the client tells the server what the contents of the record should be. These services are often called CRUD services since the client can Create, Read, Update and Delete records (though, of course, in healthcare, very few records can be truly deleted at all).

Because of the standard-based API, unlike the CDA or Consolidated-CDA, FHIR is not limited to just documents, but also supports other resource exchange frameworks including messaging, searches and operations. While data exchanged using FHIR resources can be combined to form documents, documentation is much more understandable. Small and selected piece of information is feasible to be accessed by mobile apps and clinical decision support. As an added benefit, the CDA on FHIR initiative specifies how to implement CDA R2 using the FHIR composition resource. This means that the FHIR API may eventually be extended to support CDA based data.

FHIR also leverages existing logical and theoretical models to provide a consistent, easy to implement, and rigorous mechanism for exchanging data between healthcare applications. FHIR is changing the way medical data is shared among organizations and it could be the key to big data exchange. All HIT products from lab systems to HIEs and even population health management tools will have the opportunity to leverage the new framework. With the advent of FHIR, we may witness the support for FHIR on NEHEN enabling better interoperability between members as well as beyond NEHEN network.

 

Proposed solutions

I have two possible solutions for better interoperability of providers and ACOs within states as well as the nation, where population health is especially needed. HIEs are great resources for this cause, therefore both solutions intend to use them. Some drawback of using HIEs are the fact that not all ACOs and providers currently use one, have the incentive to use one, or happen to be using the same one in their state or even county. Lack of incentives could be the cost of using HIEs, and ACOs not using a centralized HIE could be the lack of support for the data standard they use.

Kamran Ghane believes that there are two major problems with healthcare information retrieval. The first problem is lack of access to information and also incompatibility of data formats (Ghane, 2014). The first solution includes centralized HIEs in each state or region with the support for all the standards mentioned above, which are the most widely used standards by ACOs, providers and payers. Thus, more practices will be willing to join and use the HIE because it supports their types of transactions. Another feature of these HIEs is that they won’t be fee per transaction, but a monthly or yearly membership fee. In this manner, ACOs won’t hesitate to exchange data because it won’t cost them anything. The management of the HIE should also be ACOs’ responsibility and not another company’s, making it a non-for-profit.

The second problem is lack of visibility and knowledge as to where patient’s medical records reside (Ghane, 2014). I did not try to use the repository version of an HIE, instead I propose a record location service which only keeps the location of each health record that passes through it. ACOs would have to send their request for a health record to the HIE, and if it finds a match in its records, the initiator will be connected to the organization possessing the data. Since data is not stored in one place, there is also reduced risk of data loss, theft and unauthorized access. Given all that, this solution’s focus is on the state-wide implementation of a longitudinal health record, a comprehensive clinical summary of a patient-based clinical experience, as opposed to the encounter-based, or provider-based records of the past.

NEHEN uses most of those standards and there is considerable number of providers, payers and ACOs that are using NEHEN to exchange data in the New England area. It also has a membership fee instead of fee for service, and it is managed by the members. It has gained popularity and trust throughout the years. This could be a great real world proof that this solution has the potential to work, especially with updated measures such as more supported standards and using a record location service which NEHEN doesn’t have. ACOs such as Partners Healthcare which is roughly the biggest ACO in New England, who are using NEHEN, not only benefit from exchanges with other organizations, but also within their organization. Their members (Mass General Hospital, Dana Farber, etc) would be connected through NEHEN without the need to have an intra-organizational network to exchange or report data to Partners Healthcare.

Regarding public health, this method has the potential to collect locations for all the needed health records within each state covering almost every provider in that state. There is also the possibility of using customized data such as data for a specific county or city. In addition, assuming residents of each state mostly visit providers within that state, there will be very low or no intersection between datum of states. Therefore, population health researchers can aggregate and combine data from different states to reach a more desirable result with much less concern for overlapping or dependent data.

Another improvement to this solution could be a much larger scale federal HIE which is the second solution, a nation-wide implementation of virtual longitudinal health record. This solution, although much harder to achieve than the previous one, has the potential to not only know the location of almost every health record in the nation, but to help population/public health with a more thorough data. There could be two variations to this solution. One could be an aggregated version of the previous state-wide solution, and one could be an extended version of it. By aggregation I mean using the HIEs within each state, and connect them all using a higher level national HIE. It is somehow like connecting internal routers with external ones in a computer network. And by extended, I mean instead of having all those state HIEs connect, have all the providers and ACOs connect to a single federal HIE that every practice in the nation connects to. I know this particular solution seems far out of reach and it may really be. Yet to achieve greater outcomes, enduring hardships and setting higher goals are a must.

 

Clinical issues pre-solution

Numerous factors in our society underscore the need for changes to this state of isolated, fragmented health information. We are a mobile population requiring access to vital information in different locations. For example, many retired Americans receive treatment in very different locations seasonally, and increasingly prevalent chronic conditions, like diabetes, can only be managed by information-based care management. Many obvious patient safety and quality issues arise in the handoff of patients among providers that fail to share necessary information. Natural disasters displace individuals to locales with unfamiliar providers and can destroy or render inaccessible existing health information repositories. The growing use of pharmaceuticals and associated recalls of drugs from the market may call for immediate identification of affected individuals. Finally, the likelihood of serious pandemics calls for rapid identification of ill persons and accurate immunization histories. Policy makers, researchers, industry groups, and healthcare professionals identify health information exchange (HIE) as a solution to these problems.

Installing HIT systems in a physician’s office or hospital is much more complicated than installing software on a computer connected to the Internet. Although HIT systems may prevent common errors, they also have the potential to introduce new ones. For instance, overreliance on the accuracy of EMRs can lead to grievous errors if a patient record contains false information. Before selecting a health information exchange (HIE), it is important to look at the advantages and disadvantages the provider brings to the table.

Review Financial Costs.

Physicians need to carefully look at the direct and indirect costs to join and use an HIE:

  • Fees may be charged per transaction, monthly, annually or a combination of transaction and subscription fees.
  • Fees may change over time, particularly if the HIE is initially dependent upon federal funds. Inquire about how the HIE notifies physicians about price changes.
  • Cost of upgrading the office’s information technology systems to meet the HIE system requirements.
  • Costs of lost revenue and productivity during the HIE implementation phase.

Consider Liability Concerns.

The risks and liability of joining an HIE is an evolving legal field. Physicians may face complex questions and uncertainties related to liability. Primary liability concerns related to HIEs include liability for data storage and management, data accuracy, completeness and decisions made with inaccurate data.

Research any potential HIE partner and clarify special liability protection issues related to participation prior to signing a contract. Make sure to consult with legal counsel before signing an HIE contract. Physicians should also discuss the malpractice coverage in relationship to HIE participation with their insurance agent.

Data Access.

Patient data access and use can vary considerably between HIEs. It is critical for physicians to establish who has access to data within the HIE and how the information will be used prior to signing an HIE contract.

 

Clinical issues post-solution

Change resistance.

Clinicians and other healthcare professionals are typically more comfortable continuing their existing routines rather than using new technology. A major challenge with engaging many physicians is their high patient care burden, which drastically limits their time for learning what they need to know about HIEs. The workflow that included separate logins and too many clicks to get to the information proved a barrier to use. The proposed solution established health information exchange in federated models, the user’s query data sources managed by different organizations but this can be a barrier if providers need to log into multiple systems. Additionally, some organizations made it difficult for providers to get privileges to access exchanged data so those with privileges were called upon to look up information for those without access. To incorporate health information exchange system into clinical workflow more effectively, several approaches have been suggested related to changing current workflow: single login, providing training and adequate technical assistance to support the new workflow, addressing needed culture change, and having champion users.

Privacy concerns.

Patients did not want to share their medical information because of concerns about privacy. Patients concerned with privacy and security may not understand the benefits or may not consent to have their data shared with other providers. Some health care providers reported legal concerns about sharing patient data and may choose to not participate in information exchanging system. These will cause the incomplete information in the system. The result is that clinicians searching for patient information may grow frustrated if they take the time to search, do not find useful data and then they may stop using the system. To increase the availability and usefulness of HIEs, several strategies were mentioned to handle the incomplete information issue caused by privacy. These include addressing the concern about privacy with policy and training, careful consideration and design of the consent process, and the creation of a process for educating patients.

User needs.

While different HIE users have different anticipation for the information sharing in the system. Some users wanted more information and other users wanted shorter reports to avoid having to scroll up and down, click on many pages or go to another task. Some complained that the exchange contained too much information that was not filtered enough to be meaningful for providers (Ghane, 2016). Due to confidentiality reasons, exchanging clinical notes are restricted, this lack of context made the sharing information less valuable. Similarly, the lack of standardization for data entry made the information less useful. It is hard for HIEs to satisfy all the users’ requirement, particularly the one that supports big ACOs. The HIEs that automatically integrate with the EHRs may reduce this concern and the need for users to have to login into multiple systems.

 

Technical issues

The information technology industry in general and the health information technology industry in particular are ever-changing and evolving (Wager et al., 2013). There were projects like Google health and Microsoft HealthVault which have not been successful. In 2011 Aaron Brown, senior product manager for Google Health, said “Google Health is not having the broad impact we had hoped it would.” (Lohr, 2011). I believe the main reason for their failure was because they mainly focused on a specific type of health records known as personal health records. The data was being collected by individuals which had low incentive to give information and there were more human errors involved than data retrieved from accredited institutions. In the drive to apply information technology to health care, personalized health records are the element that relies most heavily on individual motivation and efforts (Lohr, 2011). The proposed solutions don’t use this kind of method, and rather than integrating data in one place it tries to make use of healthcare location services and in one solution federalize it. Clearly, there could be flaws within these solutions which will be discussed in the following paragraphs, but I tried to avoid the same mistakes in those huge failed projects.

A possible technical issue with the state-wide HIE solution is that because of using more standards, the implemented HIE would be more complex and therefore harder to implement. The system should also be able to convert those standards to send/receive to/from various users. The problem becomes much larger for the nation-wide solution. Yet to achieve such a worthy outcome, I would say it’s a small price to pay.

There is also the problem of management. As proposed, these HIEs would be managed by the members. In the state-wide HIE solution, members can have meetings and gatherings more easily to discuss problems and make management decisions, yet in the nation-wide solution it is no walk in the park. A workaround could be having the government as a neutral managing entity (this may be inaccurate) to supervise the workflow.

Another difficulty may be because of the membership/monthly fee, which may compel smaller practices to hesitate joining. This issue however, could be avoided or lessened by setting the fees based on practice’s size. On the national level, the joining of practices could be enforced by a regulation, yet it is easier said than done. Obviously, there are legal and privacy considerations to make data available to big data databases; data should be de-identified and patient must give consent to authorize the use of his personal health data in clinical research (Marcheschi, 2016). In addition, concepts of those regulations should be well defined, so there would be less misinterpretations. Take meaningful use for example, if not clarified, may result in misconception and therefore different results.

Potential Impact of problem solutions

The potential impact of these solutions on public health is enormous. Public health intentions are preventing disease, prolonging life and promoting human health. That’s not possible without the knowledge and information about the disease, it’s source, geographical area of spread, group of people it’s affecting, etc. It is like Dr. John Snow’s solution of the 1854 London cholera outbreak without his map. Without the data, public health doesn’t have the capability to do its job. With these resolutions, there will be an evolution in how public health can benefit the population in preventing diseases and promote the health of people.

There are also potential impacts on other aspects of health care. Take practice management workflows for example. With the use of HIEs, their workflows may have to be modified depending on how they previously used to exchange data, if at all. This clearly affects providers’ routines and can be mentioned as clinical workflow change. There would probably be some change resistant from registered nurses, physicians and clinical staff, especially users of the system who will be impacted directly by this change.

Then there is the technical impact. The need for high tech software and hardware systems and upgrades for almost every member in the HIE. This may also be a hassle, and mostly because of high costs. Smaller practices may have bigger problems regarding this change. There could be some loses before any profit comes of it and therefore, the impact is much harder to acknowledge for some practices compared to others. A similar example is the regulation of using ICD-10 codes instead of ICD-9. The resistance and unpreparedness was so much that it was postponed multiple times and took years for everyone to be accustomed to the idea. Yet after all that time, there were still some states (not just practices) that needed more time to adjust. That was only for a code system change. I can only imagine how that is going to be for a whole new system of data exchange.

In conclusion, the specified solutions have the potential to enable providers’ access to patients’ entire records, enhance effective communication and encourage collaboration which most probably will result in improved population health as well as health care outcomes.

 

References

Benson, T., Grieve, G. (2016). Principles of Health Interoperability: SNOMED CT, HL7 and FHIR (Health Information Technology Standards): Springer

Conn, J. (2016). Interoperability hurdles impede ACOs: Modern Healthcare

Ghane, K. (2014). Healthcare Information Exchange System based on a Hybrid Central/Federated Model. 36th Annual International Conference of the IEEE

Kasthurirathne, N. S., et al. (2015). Enabling Better Interoperability for HealthCare: Lessons in Developing a Standards Based Application Programing Interface for Electronic Medical Record Systems, Journal of Medical Systems

Levenson, J. Mukherjee, A. (2016). Why interoperability is essential for population health success: HealthData Management

Lohr, S. (2011). Google to End Health Records Service After It Fails to Attract Users: The New York Times

Maloney, N., Heider, A. R., Rockwood, A., Singh, R. (2014). Creating a Connected Community: Lessons Learned from the Western New York Beacon Community: eGEMs

Marcheschi, P. (2016). Relevance of eHealth standards for big data interoperability in radiology and beyond, La Radiologia medica

Oemig, F., Snelick, R. (2016). Healthcare Interoperability Standards Compliance Handbook: Conformance and Testing of Healthcare Data Exchange Standards: Springer

Sutner, S. (2016). Population health analytics needs interoperability:
Essential Guide

Wager, K. A., Lee, F. W., Glaser, J. P. (2013). Health Care Information Systems: A Practical Approach for Health Care Management: Jossey-Bass

 

Tables

Table 1

Code systems for healthcare information exchange

Code system Application Standard OID
RxNorm Drugs and

medication allergies

HL7 version 2,

version 3 and FHIR

2.16.840.1.113883.6.88
SNOMED CT Clinical problems

and procedures

HL7 version 2,

version 3 and FHIR

2.16.840.1.113883.6.96
LOINC Laboratory tests HL7 version 2,

version 3 and FHIR

2.16.840.1.113883.6.1
ICD-10 Diagnosis and

procedures in

eligible and claims

X12 2.16.840.1.113883.6.3