CMS interoperability rules generated quite the commotion in healthcare this past year.  But when you think about it, these mandates are pushing us closer toward the consumer-centric goals that healthcare organizations already aim to prioritize.

Interoperability Mandates Mirror Business Needs

Rules and Regulations. Regulations like the CMS Final Rule mandate that health care organizations make patient data available and shareable. The latest rule includes: Patient record API Provider directory API Payer-to-payer transfer Notification of discharge and other events BlueButton		General Trends. General trends in today’s mobile interconnected world drive many of the same outcomes: IT modernization Retiring of point-to-point solutions Move to cloud, which requires rethinking of solutions and architecture Sharing of data outside your four walls
Key Interoperability Standards. These standards are maturing and allow for easier sharing of patient data: FHIR® Smart IG/Oauth2 Open ID Connect		Business Needs:  Need for business agility and resilience Healthcare consumerization Mobile Demand for better healthcare outcomes Manage challenge of combined/colliding provider and payer functions

Integration and Interoperability: Boosting Consumer Experience and Innovation in Healthcare

To remain competitive and compliant, healthcare organizations are:

• Ramping up real-time data exchanges across a growing web of communication points
• Leveraging data models for batch, EDI, and HL7® sharing
• Integrating with external AI models
• Managing communications and care delivery across mobile and medical device applications

Through it all, patients and members expect to engage across multiple channels.

RELATED: Interoperability Options for Healthcare Payers: Meeting the CMS Final Rule (and Beyond)

Healthcare organizations’ ability to accelerate transformation is crucial so your organization can adapt and flourish in an increasingly competitive and ever-changing landscape. We recently published a video that explores this opportunity:

EXPLORE MORE: Healthcare PowerByte: Interoperability – Make Data a Strategic Business Asset

A Data Integration Partner for Leading Healthcare Organizations

We help the largest payers and providers in the U.S. strategize, plan, and deploy transformative change with lasting impacts – providing high-quality and affordable care, engaging and empowering consumers on their healthcare journey, and positioning their organization for innovation, agility, and efficiency. Read about some of the successes our integration, interoperability, and data experts have helped organizations achieve:

• Empowering Healthcare Consumers and Their Care Ecosystems With Interoperable Data: Wanting to do more than simply meet the CMS interoperability mandate, our payer client seized the opportunity to build a scalable infrastructure that mobilizes data in ways that truly put the consumer first – giving all members secure access to their health information when they need it most and in a way they can best use it.
• Cloud-Based Business Solution Streamlines User Experience and Reduces Costs: Our solution created new functionality for the healthcare services company’s users, optimized internal operations, and increased member adoption and dollars saved for its provider network.
• Collaboration Boosts New Patient Acquisition: Ownership of data and the flexibility to truly integrate open scheduling were paramount, so the health system did not want to outsource to a third-party application. We innovated an API-based open scheduling integration with Henry Ford’s MyChart EMR system. We further integrated the scheduling system with Cadence, which Henry Ford physicians use to manage their schedules.
• Driven by Core Principles to Enable a Healthy Community: We equipped our client with a foundation to deliver mobile solutions and integrate with external vendors

Interoperability and Integration Are Driving Healthcare’s Future

Healthcare leaders have access to more healthcare data and technology than ever before allowing them to transform patient and member care. A one-size-fits-all-approach doesn’t work anymore and we’re being challenged to do more through personalized medicine.

In season 1 episode 2 of the Intelligent Data Podcast, host Arvind Murali and his guest Juliet Silver, Perficient’s Chief Strategist of Healthcare, discuss the state of affairs in the healthcare industry including the “Triple Aim”, the COVID-19 pandemic, IoT in healthcare, and more.

We’re also looking at the patient or the member as a consumer as well. And we’re seeing a big shift from payors and providers, because they’re looking at the consumer in the same way as other industries do. So we’re starting to paint that picture with data around the lifetime value of that consumer and we’re leveraging data both internal and external to market to them, to reach out and engage with them, and to be able to capture interactions and preference data. – Juliet Silver, Healthcare Chief Strategist

Listening Guide

Healthcare Data is Changing Consumer Care

• Data, analytics and healthcare consumerism [3:10]
• “Patient” to “Health Consumer” [7:58]
• Triple aim and leveraging third party data (Peloton, Fitbit, etc.) [9:10]
• How the COVID-19 pandemic has affected the healthcare industry [10:58]
• Physician burnout data [13:10]
• Telehealth and volume-based versus value-based care [15:39]
• AI’s impact on healthcare [17:15]
• How do you govern IoT healthcare data [21:30]
• New interoperability mandates for FHIR standards [25:06]
• Data accessibility, transparency and portability creating consumer choice [26:55]
• Data ethics, data privacy and data security [29:33]
• Healthcare Data-driven solution case studies [31:43]
• Advice to executives as they prepare for a post-COVID world [33:58]

Get This Episode Where You Listen

And don’t forget to subscribe, rate and review!

Apple | Google | Spotify | Amazon | Stitcher | Pocket Casts

Connect with the Host and Guest

Arvind Murali, Perficient Principal and Chief Strategist

LinkedIn | Perficient

Juliet Silver, Perficient Chief Strategist of Healthcare

LinkedIn | Perficient

Learn More About Our Healthcare Solutions

If you are interested in learning more about Perficient’s Healthcare services capabilities or would like to contact us, click here.

The Perficient project lead handling an Enterprise Integration project at one of the largest healthcare providers in the country called me one afternoon and asked me to find a quick solution to write HL7 messages in XML format as some vendors that were being integrated needed the messages in XML. I knew that the solution had to be simple and I assured him of that.

Representing the HL7 message in XML format is not normative below v.3, and they are represented in physical format as TDS(Tagged/Delimiter String) messages. The TDS format of the message implies that the parser has the message schema(message set) available, which it uses to parse and validate the messages. The XML format is self-defining, while constraints on the message can be defined through XSDs .

I began to think about how to accomplish the task without accessing every HL7 field and copying every single field to the output XML. In IIB, data is represented in trees, parsed TDS messages are no different. After the incoming HL7 message is parsed, it is under the data part of the Root(Body). The names of the fields appear as defined in the message schema.

In view of this information, to accomplish the task,  I realized that it just suffices that the parsed content in the InputBody be assigned to the OutputRoot while using the XMLNS or XMLSNC parser. After this is done, while writing the output message, IIB writes the data in XML format. If the DFDL message set and parser are used, then the following has to be done:

SET OutputRoot.XMLNSC = InputRoot.DFDL;

Since, XML is self-defining, it does not need a message set to specify the physical format of the data. But, if validation of the values is required, it has to be made sure that the properties part of the Root contains a reference to the message set and of course, validation has to be turned on at appropriate exit points. Both DFDL and MRM message schemas in IIB are model driven and they will validate the values before writing the output XML. For example, if the name of the message set is HL7v251DFDLSharedLib, then:

SET OutputRoot.Properties.MessageSet = ‘{HL7v251DFDLSharedLib}’;

For physical formats of the input and output, please refer below:

Input message:

Output XML:

The field names in the output XML as defined in the message schema  can be changed by modifying it.

Note: 1) IBM provides a HL7 healthcare pack with message sets both in MRM and DFDL formats with various HL7 nodes. DFDL formats are defined for v 2.5 and above. To avail this, the IIB Healthcare pack has to be installed on the top of IIB installation.

2) HL7 v.3 now provides specification for the HL7 messages in XML.

CHALLENGES MAKING MASSIVE AMOUNTS OF DATA MEANINGFUL 

Healthcare data requires high security – but that can also lead to difficulty in sharing information when needed. Interoperability of healthcare data requires a modernized infrastructure to enhance communication and access. With restrictive formats like EDI and HL7, along with the unstructured data generated by wearables and devices, providers and health plans have to find faster, easier ways to exchange this data in order to provide better care.

Healthcare organizations need to transform this large volume of data into actionable insights that improve the quality of care and reduce overall costs.

APIs INCREASE INTEROPERABILITY 

APIs can clearly define transmission and security rules for data exchange between systems within a healthcare provider or plan and between organizations. With integrated services, APIs can speed the delivery of interoperable services while increasing the security of patient data. APIs can support Fast Healthcare Interoperability Resources (FHIR), the latest proposed interoperability standard developed by HL7 for data formats used in clinical systems. With FHIR’s modern web services approach, interest and adoption in the healthcare IT community is growing. Organizations must be ready to create systems that can handle this new data exchange technology and those that will proceed it.

It is critical for organizations involved in M&A activity to keep consumer experience a priority. Leveraging shared data and services will be a key to delivering a cutting-edge digital experience for their existing and newly attained consumers. Data integration from all sources and systems is an enormous undertaking, but one that will be the cornerstone of success.

Information deluge is just one of the healthcare challenges alleviated by API management outlined in our guide, Digitally Transforming Healthcare with APIs. Download the guide for the other ways APIs are changing healthcare and get real-world success stories from industry leaders.

In the European Union, the use of E2B(R3), along with IDMP, is in legislation, so not complying by the deadline could have legal repercussions. Non-compliance with the FDA and MHLW’s requirements could also bring unwanted scrutiny. More importantly, if an organization does not comply by the deadlines, they will not be able to send ICSRs automatically to regulatory agencies. Nonetheless, if an organization’s safety and pharmacovigilance system does not have the ability to submit data in the new E2B(R3) format, they can still transmit the information via web-based solutions, such as EMA’s WebTrader.

Navigating regulatory guidelines and requirements is a challenge that all life sciences organizations must confront in order to protect the safety of patients, as well as to shield themselves from the dire consequences that can be imposed by global regulatory bodies.

As a company that has assisted hundreds of organizations with their clinical and safety system implementations and integrations, Perficient is in a unique position to help biopharmaceutical, medical device, and contract research organizations assess their situation and provide trustworthy recommendations they can depend on. While the commercially off-the-shelf adverse event reporting system we specialize in is Oracle Argus Safety, our team has the industry experience that organizations can turn to for all of their technology needs.

To learn about E2B(R3), the impact it is likely to have on drug safety business processes, and some ideas for how to move forward, fill out the form below or click here.

Yes, some validated systems can comply with E2B(R3). With respect to Oracle Argus Safety, the current version, 8.0.1, is able to comply with E2B(R3), Electronic Vaccine Adverse Event Reporting System (eVAERS), and Electronic Medical Device Reporting (eMDR) reporting requirements.

If a company is simply looking to meet E2B(R3) requirements, we advise waiting to upgrade until the EMA finishes testing and provides feedback to the industry. The testing should be completed by mid-2016. Nonetheless, organizations will not be able to transmit messages using the E2B(R3) format until after the audit of the new EudraVigilance, which is mid-2017.

If an organization has questions about whether a system is E2B(R3)-compliant, the software vendor or a reputable partner should easily be able to determine whether it meets regulatory requirements.

To learn about E2B(R3), the impact it is likely to have on drug safety business processes, and some ideas for how to move forward, fill out the form below or click here.

The issue is not the type of system used to collect adverse event data, but rather how the data is submitted to the FDA, EMA, and MHLW. If an organization is using spreadsheets to collect safety data or is unable to transmit data via E2B, it will have to report the data via a web-based tool, such as the FDA’s WebTrader or EMA’s EVWEB.

To learn about E2B(R3), the impact it is likely to have on drug safety business processes, and some ideas for how to move forward, fill out the form below or click here.

Companies who are currently submitting reports using the E2B(2) format should already be planning the move to E2B(R3). If a robust safety and pharmacovigilance system is already in place, there are likely just a handful of technical changes that need to be made in order to meet the new regulations. For example, system configuration changes that affect reporting destinations could be required. That said, most companies will likely want to look at additional information that could be sent using E2B(R3) to provide a more robust ICSR.

To learn about E2B(R3), the impact it is likely to have on drug safety business processes, and some ideas for how to move forward, fill out the form below or click here.

In the United States, if a company is transmitting vaccine or device information to the FDA, it should already be reporting in E2B(R3) format. For companies reporting solely to the FDA Adverse Event Reporting System (FAERS), no official deadlines have been published.

In Europe, drug companies who report to the EMA will need to comply with the new format by mid-2017, following the audit of the new EudraVigilance system.

In Japan, if a company transmits ICSRs to Japanese regulatory authorities, mandatory reporting using E2B(R3) is set for April 1, 2019.

It is essential to note that if a company transmits data in the E2B(R3) format to a company whose systems do not accept it, the receiving company would need to convert the message into an E2B(R2) format, in order to make sense of it.

To learn about E2B(R3), the impact it is likely to have on drug safety business processes, and some ideas for how to move forward, fill out the form below or click here.

Currently, two of the FDA branches have released guidance documents and have implemented a form of E2B(R3). Center for Biologics Evaluation and Research (CBER) has released “Providing Submissions in Electronic Format — Postmarketing Safety Reports for Vaccines” and the Center for Devices and Radiological Health (CDRH) has released “Technical Information on eMDR.” While both of these branches have required E2B submissions since 2015, no new guidance has been published by Center for Drug Evaluation and Research (CDER), although the group is very likely to issue guidance sometime in 2016. Pending new guidance, if an organization manufactures vaccines or devices, it will likely be required to submit its safety data to regulatory authorities in the new E2B(R3) format.

Exactly when the European Medicines Agency (EMA) will require submissions to be in E2B(R3) format depends on the completion of a successful independent audit of the new EudraVigilance system, in addition to the implementation of the Identification of Medicinal Products (IDMP) guidelines. The audit will check that the required functionalities, agreed to by the Pharmacovigilance Risk Assessment Committee (PRAC) and the EMA Management Board in December 2013, have been implemented. The audit report, along with a PRAC recommendation, will be presented to the EMA Management Board, who will then announce whether the EudraVigilance system has sufficiently implemented the functionalities. This falls in accordance with EudraVigilance stakeholder change management plan. At the EMA stakeholder’s day in December of 2015, the EMA stated that they hoped the requirements for mandatory submissions using E2B(R3) would be in place by in mid-2019.

Japan’s Pharmaceuticals and Medical Devices Agency (PMDA) has stated the interim period for submitting data in both E2B(R2) and E2B(R3) formats is between April 1, 2016 and March 31, 2019. Essentially, this suggests mandatary submission using E2B(R3) would begin April 1, 2019.

To learn about E2B(R3), the impact it is likely to have on drug safety business processes, and some ideas for how to move forward, fill out the form below or click here.

After the release of E2B(R2), the ICH realized that technical specifications should no longer be developed in isolation. E2B(R3) is the first technical specification to be developed through a new collaborative approach.

E2B(R2) Vs E2B(R3): Regulation and Interoperability

The International Organization for Standards (ISO), Health Level Seven International (HL7), and European Committee for Standardization (CEN) collaborated to form the Joint Initiative on SDO Global Health Informatics Standardization, through which a single, common standard for the ICSR could be advanced. Subsequently, the Clinical Data Interchange Consortium (CDISC), the International Health Terminology Standards Development Organisation (IHTSDO), and GS1 became members of the Joint Initiative. ICH representatives have also been heavily involved.

The overall standard is based upon a HL7 ICSR model that is capable of supporting the exchange of messages for a wide range of product types (e.g., human medicinal products, veterinary products, medical devices).

The real benefit of E2B(R3) is interoperability, which ultimately better protects patients and consumers.

Since E2B(R3) is based on HL7, a variety of clinical systems will be able to use it to exchange data with each other. With this new structure, more data can be passed to regulatory authorities or marketing authorization holders, making the information much more valuable to all parties involved.

READ MORE: What Is E2B(R3)?

Life Sciences Leaders Turn to Us

Life Sciences leaders rely on us for strategic and technical expertise to achieve their missions in a technologically advancing industry. Our experts are here to support you in achieving your business goals and solving your most complex technology challenges. 

To learn more about E2B(R3), the impact it is likely to have on drug safety business processes, and some ideas for how to move forward, fill out the form below or click here. Contact us, to discuss your specific needs,

E2B(R3) doesn’t have a direct translation. The International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH) published guidelines that have designated “E” to stand for efficacy. The work carried out by ICH under the efficacy heading relates to the design, conduct, safety, and reporting of clinical trials. It also covers novel types of medicines derived from biotechnological processes, and the use of pharmacogenetics and genomics techniques to produce better targeted medicines. All “E2” guidelines relate to pharmacovigilance. The official E2B(R3) document is titled “Clinical Safety Data Management: Data Elements for Transmission of Individual Case Safety Reports.”

There was a time when people shared safety information on a hand-written forms. Then, E2B was introduced. E2B essentially defines what data elements need to be transmitted in individual case safety reports (ICSRs), regardless of the source or destination. E2B(R3) is actually the fourth major revision of E2B guidelines.

The FDA, EMA, and Japan’s Ministry of Health, Labour and Welfare (MHLW) have all confirmed they will adopt E2B(R3) as their standard submission format. All companies that currently report safety data to regulatory agencies or partners using E2B will be required to adopt the new E2B(R3) format.

To learn about E2B(R3), the impact it is likely to have on drug safety business processes, and some ideas for how to move forward, fill out the form below or click here.