In Search of a Collective Source of Truth

While the design competition called for a solution to create a single source of truth, the GHX proposed solution recognizes that disparities in technological capabilities, the need for different product attributes for different purposes, (e.g., procurement, distribution, payment, clinical research, etc.), and varying regulatory requirements, among other things, will require a collective effort to generate accurate, comprehensive, relevant and current data about medical products.

1

The need for a collective source of truth is amplified by the move to value-based healthcare, under which products need to be viewed from multiple perspectives, to assess factors ranging from quality and efficacy to impacts on the total cost of care.

Human nature prefers a more streamlined approach and naturally desires a single source of truth, but the reality is getting to the full and relevant truth about products requires multiple 2

parties, processes, and technologies working in concert to create a continual learning system of knowledge about medical products.

While there are many pathways to get to different aspects of the truth, the use of standards deployed at the system level can clear some of the complexity and confusion along the way.

These include standard identifiers, standard protocols to communicate data, and standard data structures.

3

The reality is we live in a world of numerous systems and standards. Even with unique device identification regulations, there are multiple standardized coding systems that are “UDIcompliant” (the GS1 Global Trade Item Number (GTIN), the HIBCC LIC, and the ICCBBA ISBT 128 code). There are also numerous systems to classify and categorize medical products, each with a primary purpose, e.g., the Global Medical Device Nomenclature (GMDN) has been the primary coding system used by regulators, although both the European Union and the World Health Organization (WHO) are developing their own systems. Meanwhile, supply chain professionals are more familiar with the United Nations Standard Products and Services Code (UNSPSC), the Universal Medical Device Nomenclature System (UMDNS), and eClass in the UK and Germany. There have been efforts to define the relationships between various systems by creating maps between some of the classification codes, most notably the GMDN and the Systematized Nomenclature of Medicine – Clinical Terms (SNOMED CT), which is more commonly used for clinical purposes. Challenges remain because the different systems have different data structures, although some of the resulting confusion can be minimized by linking the classification codes to the actual device identifiers, e.g. the UDI device identifier (UDI-DI).

Any system to support a collective source of truth must be able to support these different identifiers and classification schemas and create the various linkages between the systems.

Further, various technologies also utilize different communication protocols, all of which must be secure given the sensitive nature of healthcare data. These include AS2, AS4 and Secure FTP, and once again, a solution to create a collective source of truth must also support these various modern encrypted data transport protocols.

Finally, a system must support the various financial models in healthcare, the technology systems in use, the regional regulatory requirements and the needs of various stakeholders.

4

Depending on which stakeholder is using the data, and for what purpose, there are various product data attributes needed at various stages along the path to value. The ultimate goal is delivering value to patients, but to make the system work, value must also be delivered to each stakeholder and process along the way to create the business case for the investment in new processes and systems to manage data to support a collective source of truth.

5

Slide 8 illustrates some of the different types of data needed at the various stages. Many of these are attributes about the products themselves, but to generate data about the cost and quality of products used in clinical practice, as an example, data is often needed about the patients themselves and about the facilities in which those products are used.

6

As a result, a collective source of truth is needed to manage data that is universal in nature, i.e., it is the same regardless of the activity or stakeholder. For example, the UDI-DI should be the same regardless of whether a product is being packaged for delivery by a manufacturer or being used in patient care. The data about the device composition, as well, should not change, e.g., whether it contains latex or is MRI compatible.

On the other hand, there are data elements that are very specific to the organization or individual using a product and the patient for whose care it is being used, e.g., the contract price paid by a specific healthcare provider, the clinical factors specific to the patient, and the production data (e.g., lot, serial number, expiration date) for the specific product being used.

It is a combination of these universal and conditional data factors that enable research into how a particular device contributes to both the quality and cost of care.

7

Further complicating the search for “truthful� product data and underscoring the need for a collective approach are the various regulatory requirements. For example, both the U.S. and Europe are instituting a unique device identification system aligned with the International Medical Device Regulatory Forum guidelines, but there are slight differences in the data attributes required in their respective databases, as well as the classification system (GMDN for the U.S., the under development European Medical Device Nomenclature in Europe).

Meanwhile, the Scan4Safety programme and the eProcurement Policy in the United Kingdom require use of only GS1 identifiers, the Global Data Synchronization system for data submission, subscription and publication, and the PEPPOL technical specifications for exchange of eProcurement documents. These regional differences will only become more complex as additional jurisdictions implement their own regulatory frameworks for clinical, financial, and operational aspects of healthcare.

8

With this understanding of the complexity and need for multiple data sources, provider organizations should begin by identifying WHAT data is needed for what purpose, from WHERE that data can be obtained, and as importantly, HOW that data will be accessed, consumed and shared. As noted earlier different data structures and disparate technology can make consuming and sharing data challenging.

9

Given the importance of manufacturers as the original producers of data related to their products, and a growing demand for more attributes about their products, tools should be put in place to make it easy for manufacturers to aggregate the data from multiple sources within their own organizations, and to disseminate that data to multiple users for multiple purposes, e.g., regulatory bodies, supply chain, clinical researchers, etc. Often data users (other than regulatory) need data that is not provided by manufacturers, e.g., revenue codes, classification codes used for spend analysis, etc., that must often be augmented by third parties. Those organizations can also provide tools that deliver data that is relevant to the user and more easily consumed by technology systems.

10

The proposed solution must also provide capabilities to streamline workflows by enabling a product barcode or other auto id and data capture carrier to be scanned once and link to the data used for multiple functions, and shared and consumed by different users and systems.

So far, we have primarily discussed data that is already available, primarily from manufacturers of the products. But other data, such as clinical data on how products perform in routine 11

clinical practice on different patient populations, must be created. The need for this data will only grow in part due to regulatory requirements, e.g., the post market aspects of the European Medical Device Regulation (MDR) as well as the overarching need to understand how products contribute to value-based healthcare and outcomes that matter to patients relative to the costs to achieve them.

This data will be created and analyzed by multiple parties and better insights come from more robust data sources and review by other experts to ensure proper methodology and identify any potential biases or defects in the data, etc. As more data is generated by proper research methodology on different products used on different patient populations, more confidence in the data is enabled.

12

This data is generated by different providers, researchers, and payors and requires data capture in many systems, including electronic health records (EHRs), registries, and claims. In all cases, standard identifiers, e.g., the full UDIs (both device and production identifiers) must be used.

13

With this understanding of the expanded uses of data and the different parties involved in data generation, further questions arise on what kind of product data attributes are needed for multiple purposes, e.g., to make it easier to know which barcode to scan, to know if products are recalled or on backorder and if so, what products are clinically equivalent, and if products are deemed to be environmentally friendly and if so, under what criteria. Some of these determinations are subjective, e.g., clinical equivalency, environmental sustainability, but should be based on expert knowledge.

The breadth of different data needs and the potential for different expert opinions regarding different data attributes further requires a larger community of data contributors and platforms upon which they can share, use and evaluate the quality of the data. In this way, the community provides an additional layer of “peer review� and can offer reputation scores on the sources of the data. GHX and Hashed Health are currently exploring with industry design partners (providers and suppliers) if blockchain technology could be deployed to support a data market (e.g., enabling providers and others to sell curated data with community-derived reputation score development).

The solution proposed by Global Healthcare Exchange (GHX) addresses the topics discussed thus far, some of which have already been proven successful through use of existing GHX solutions in specific markets and could be further developed to address the needs of multiple markets, while others would be developed in conjunction with a larger and broader community (and could include the solutions proposed by others semi-finalists in the 2019 design competition). At the foundation of the proposed solution is an existing multi-stakeholder provider and supplier community that transacts millions of basic and advanced EDI and XML 14

transactions with one another across the GHX exchange. GHX is currently connected to the majority of healthcare systems in the US and the UK, a large percentage in Canada and Germany, and with many others in seven additional European countries and to the manufacturers from which they purchase 85-90 percent of their medical-surgical products services. This B2B platform supports use of standards for product and organizational identification, aggregation of data from multiple sources (e.g., GUDID, GDSN, direct from manufacturers, etc.), augmentation of additional data attributes, and the ability for users to receive data relevant to them in an easily consumable format in EHR and ERP systems. A solution could expand to work with other technology systems and organizations, e.g., registries, claims, payors, etc.. Data is also currently shared across modern encrypted data transport protocols, e.g. AS2, AS4 and Secure FTP and could be expanded through further development and use of APIs. GHX currently offers virtual item masters to more than 200 facilities in North America, which helps overcome limitations with existing on-premise technology systems, and supports the ability for manufacturers to load data into the Global Data Synchronization Network (GDSN) and the Global UD Database (GUDID). GHX has also helped providers in the UK with the Scan4Safety programme, in Canada (e.g. Alberta Health Services) and Mercy (St. Louis) consume data published to GDSN by manufacturers to support various efforts to improve patient safety, understand total cost of care, and generate real world evidence on product performance. As part of the design competition, this could be further expanded to other regions, data consumers and for additional regulatory requirements. Finally, the blockchain initiative mentioned previously could support the growing demands for different data attributes about products, not all of which can be provided by manufacturers and which are not included in regulatory or existing commercial (e.g. GDSN) databases.

15

To summarize, the GHX proposed solution will explore what has proven successful in specific parts of the world and/or with a subset of the GHX community to see if the value is repeatable/generalizable to a broader user group operating under different financial and regulatory systems, and to explore what are the common elements that define success or failure.

Further research would be conducted to understand what level of value must be achieved for the various parties in the ecosystem to build the business case for investment in change management around processes and new systems for data management.

The blockchain initiative will provide important research on whether this technology is appropriate to support a community driven data exchange with expanded data attributes.

The proposal would also explore how to complement and/or incorporate other proposals put forth by semi-finalists in the design competition.

16

17