Roche Diabetes Care interoperability Guide
based on FHIR R5

Overview


This R5 Implementation guide - or One RDC Interoperability guide - describes how information is represented in FHIR R5 standards and how the data can be exchanged through standard APIs.

This information will be helpful to systems engineers, and system programmers and it focuses on the API definitions that are necessary to provide connectivity between Roche and external systems. Promoting interoperability Roche provides timely and seamless portability of information and optimise the health of individuals and populations globally.

Purpose


This Implementation Guide defines the use of FHIR resources to convey measurements and supporting data from Roche Diabetes care associated applications like mysugr, confidence to receiving systems for electronic medical records, quality measurement and research purposes.

How do we design this Implementation Guide

This Implementation Guide is designed as single source of truth for the understanding how to integrate with Roche Diabetes Care. This is achieved through the representation of datapoints and its corresponding FHIR modelling as Profiles which can be easily exchanged using global exchange formats like JSON & XML.

As such, this guide includes only a small subset of the Datapoint, Profiles and technical attributes that are internally managed, focusing on enabling the data model needed to reliably, securely, and easily exchange data with external partners.

FHIR provides a platform specification. A single set of resources (building blocks) for many different contexts. In order to fit our required context, adaptations will be necessary. These adaptations are basically called “Profiling”

Some of the adaptations are:

  • What elements (fields and complex data structures) of the standard FHIR specification are used
  • What is the cardinality and data type of each element
  • The specific semantics (Terminologies) that are enabled when appropiate.
  • Syntactic Extensions to the FHIR Standard that enable interoperability of specific and nuance Diabetes data concepts.

how-do-we-design

How to read this Guide

This Guide has the following sections:

  • Profiles - Contains the list of all profiles supported in Roche Diabetes Care Interoperability layer, ordered and segregated by resource type. It also contains the detailed structure definition showing the elements used, cardinality, data types, terminologies etc. In order to ease integration, the guide also offers one or various examples of valid JSON Payloads per profile.

  • Extensions - Extensions are used to cover additional but valid Diabetes-specific requirements in an implementation that are not in the specification. The FHIR specification is based on generally agreed common requirements across healthcare - covering many jurisdictions, domains, and different functional approaches. It is common for specific implementations to have valid requirements that are not part of these agreed common requirements. More details at - https://www.hl7.org/fhir/R5/extensibility.html

  • Data catalog & Terminology - Contains the list of Datapoints that are made available for interoperability Data catalog, list of CodeSystems/ValueSets supported by Interoperability. Value set specifies a set of codes defined by code systems that can be used in a specific context.

  • Implementations - Technical details about the FHIR Server variants that implements this IG. Each implementation may serve different purposes and as such, a subset of the datapoints and profiles may be implemented.

Data scope and Data Semantics

This interoperability guide enables a small subset of all data managed by Roche Diabetes Care Digital product portfolio, selected due to its business relevance and medical value. This scope is disclosed as part of this Implementation Guide Catalog and Terminology scope.

Code Systems, Value Sets and terminologies

CodeSystems define a set of codes with meanings (also known as enumeration, terminology, classification, and/or ontology)

CodeSystems are used in ValueSet resources. In resources (Patient, Device, Observation, etc...), the Coding data type refers to CodeSystem resources by their canonical url.

The CodeSystems, Value Sets which are terminologies have the ability to exchange information and have the meaning of the information preserved upon receipt. It is here that interoperability codes such as LOINC, SNOMED CT, Roche Internal codes are critical, as they provide a common language to identify health care data. we explain the major coding systems here in detail.

LOINC : Logical Observation Identifiers Names and Codes (LOINC®) is a coding system used to describe laboratory observations and is the preferred method in HL7 to identify laboratory tests (https://www.hl7.org/fhir/observation.html#code-interop). As such, LOINC codes represent the “question” of a test or measurement (https://loinc.org/get-started/what-loinc-is/). Each LOINC code consists of several components or parts, and each part provides a specific piece of information (https://loinc.org/kb/faq/structure/).

SNOMED CT : SNOMED CT, or the Systematized Nomenclature of Medicine Clinical Terms, is a comprehensive, multilingual clinical healthcare terminology. Like LOINC, it's designed to support the consistent recording and exchange of clinical information, enabling interoperability between different health systems. Each SNOMED CT code represents a unique clinical concept, which can be a disease, symptom, diagnostic procedure, or other aspect of clinical care.

Roche internal codes :

It is clear that using Roche internal codes reduces the degree of semantic interoperability of RDCP as it requires the distribution of data dictionaries to data receivers. However, some concepts and observations will require such a definition as external standards will not allow us to capture them. Thus, in order to reduce the use of Roche internal codes to a minimum, we recommend the following decision process that represents an order of preference:

  • If a LOINC code is available for an observation, use the LOINC code
  • If a SNOMED CT code (subject to the constraints mentioned above) is available for an observation, use this code
  • If a combination of a LOINC code for the Observation.code field and a SNOMED CT code (subject to the constraints mentioned above) for the Observation.method field can adequately describe an observation, use this combination
  • If a combination of a SNOMED CT code (subject to the constraints mentioned above) for the Observation.code field and a SNOMED CT code (subject to the constraints mentioned above) for the Observation.method field can adequately describe an observation, use this combination
  • Only if none of the above is applicable, define a Roche internal code for the Observation.code field

NameSpace(Profile Naming) of this Implementation Guide

In the Interoperability Implementation guide we have multiple profiles available for FHIR resources. As an example, under Observations we have BG, Vital-signs and so on. These profiles define the expected structure i.e what elements are mandatory, what are optional, what are the valueset bindings and so on. The profiles are common across multiple applications. It is possible that sometimes, an profile may need some changes to the structure which could be incompatible/not required with other data points using the same profile. In this case creating NameSpace of profile may be necessary.

example : while considering for Interoperability, we have requirement to use observation profile for Blood glucose use case which will have unique extensions /modelling structure which may not be required for other observation use cases.

So, we are classifying Observation further with "new canonical url", where structure definition classification would be integrated in url.
example : (http://roche.com/fhir/iop/StructureDefinition/BG_Observation)

How to use Namespace for validation:

  • Indicate the field meta.profile complete StructureDefinition url to validate the resource. (e.g.: "meta":{"profile": "http://roche.com/fhir/iop/StructureDefinition/BG_Observation"}.
  • If meta profile is not specified, validate will consider the R5 structure definition by default.,


Note: This is used for the technical side, for validation of profiles.

Development and versioning of this Implementation Guide

Versioning

This interoperability guide will be evolved periodically in order to support new datapoints, FHIR Resources or terminologies based on the need of our partners. A version strategy is set in place to support compatibility:

  • X.0.0 - Major revision. An incompatible change has been introduced to one or multiple FHIR profiles that requires the FHIR servers to provide new non-backwards compatible interfaces or a mapping strategy.
  • 0.X.0 - Minor revision. A backwards compatible change has been introduced by either adding a new FHIR profile, new attributes to an existing FHIR profile or a new terminology that do not impact nullability or cardinality
  • 0.0.X - Patch revision. Introduction of a backwards compatible bug fix or small tweak to existing profiles, existing attributes or terminologies

This versioning strategy is based on the Semantic Versioning 2.0.0.

You can check the complete changelog history HERE

Implementation Guide code sources

Currently the whole project is self-hosted in simplifier, but we plan to start using a Git Repository to trak all documentation changes with their associated changelogs.

Implementations of this IG

This implementation guide has been designed to be a generic, extensible and standard FHIR model that can be implemented in multiple types of FHIR Servers aimed at solving different use cases.

Hosting

This interoperability guide is hosted in Simplifier as part of the Roche Diabetes Care project. If you wish to navigate the whole project and the different implementation guides, you can create a free account and request an invitation to any of the team members that design and mantain this IG.

Data Design team

This implementation guide is designed and mantained by the Data Architecture team from the Digital Development group in Roche Diabetes Care
Team_photo_Aleja Team_photo_Alej Team_photo_Chand Team_photo_Albe
Global Head of Big Data
alejandra.manrique@roche.com		 Senior Data Architect
alejandro.montero_rivero@roche.com		 FHIR Data Modeler
chandru.annamalai@businesspartner.roche.com		 Data Modeller
alberto.blazquez_herranz@businesspartner.roche.com