Slides for the IEEE Blockchain Symposium in Glasgow, https://blockchain.ieee.org/standards/clinicaltrialseurope18, https://blockchain.ieee.org/standards/clinicaltrialseurope18/speakers

1. THE NEED FOR INTEROPERABILITY IN BLOCKCHAIN-BASED
INITIATIVES TO FACILITATE CLINICAL TRIALS: A COMBINED
IHE/HL7 APPROACH
https://www.grapevineworld.comGlasgow, IEEE Blockchain Forum
Massimiliano Masi / Abdallah Miladi
November 15, 2018

2. Interoperability is a key to establish sustainable health IT services
Interoperability can‘t be achieved by only using a standard
DLT may offer a technological solution with high risk for vendor lock-in
Cryptography of blockchain is tamperproof, but IT security is vulnerable
Enterprise Architecture comes to the rescue
Massimiliano Masi: Intro to Blockchain ©Grapevine World GmbH 2/30

3. INTEROPERABILITY AS A KEY ENABLER TO BUILD
SUSTAINABLE HEALTH IT SERVICES
• ISO 27002 introduces the CIA triad
• Himss defines interoperability in three levels:
• Foundational (at the level of message exchange)
• Structural (at the format of data exchange)
• Semantical (at the level of information exchanged)
• If interop levels are not met, data is not available, violating
ISO dictates
• Cost reduction (switching between supplier)

4. STANDARDS ARE
NOT ENOUGH
• «The nice thing about standards is
that you have so many to choose
from» (A. Tanenbaum)
• «Standards alone are not enough to
guarantee interoperability» (G. Lewis)
• Open Source is not enough, adapters
proliferate
• Enterprise Architectures comes to the
rescue
• By defining concepts, rules, and
building blocks, EA (e.g., TOGAF,
IHE) enables component continuum
• See HL7 FHIR vs HL7v3 vs HL7v2 vs
RLUS, vs CDISC …
• IHE has been part of a Juncker’s
Commissin decision for health IT

5. CONCEPTS
• Reference Architecture is the generic architecture providing guidelines and options for
developing specific architectures and solution implementations. Here it refers to the set
of all available profiles used to build a solution architecture
• Solution Architecture describes the specific business operations/activities and the
ways in which information systems and technology support them. It typically applies to a
single project/organization.

6. CONCEPTS / 2
• Actor is a functional component of the healthcare, or energy, organization.
• Transaction is a standards-based specification of the interactions between IHE Actors.
• Profile is a high-level functional unit composed of related IHE Transactions, with the
capacity to address specific IT infrastructure requirements for a single case.
• … and they can also be formalised1
1 H. Aranha, M. Masi, T. Pavleska, Automatic Smart Grid Solution Architecture Design, in IEEE SmartGridComm 18

7. THE IHE MODEL

8. STANDARDS FOR CLINICAL TRIALS?
• http://www.consort-statement.org/examples/sample
• http://www.transceleratebiopharmainc.com/initiatives/clinical-data-standards/
• https://www.cdisc.org/standards
• OASIS
• W3C
• OMG (Object Management Group)

9. EXAMPLE: IHE QUALITY, PUBLIC HEALTH, RESEARCH
(QRPH)
• QRPH is a mature domain from IHE
• Devoted to the foster the coordinated use of established standards in the areas
• Share information relevant to quality improvement in electronic patient care and
health​care records
• Facilitate interoperability between the clinical care system and clinical research
• Facilitate interoperability between the healthcare system and public health

10. RELEVANT PROFILES AND DEPLOYMENTS
• Clinical Research Document, describes the content pertinent to the clinical research use
case
• Drug Safety Content, Standardizes pre-population of adverse event report fields
• Retrieve Process for Execution, Accesses a process definition, such as a research
protocol, and executes automated activities without leaving an EMR session
• National Center for Health Statistics, UC Davis, UUHC Utah, US Center for Disease
Control
• EU C2-Sense (mapping to Emergency Data Exchange)
• Supported by GE, ITH Icoserve, Qvera, Forecare, Aegis,

11. HEALTHCHAIN PILOT
• A two-stage pilot with
• Grapevine,
• Microsoft
• Tiani Spirit,
• University of Southampton
• Based in DE/AT/UK
• Exploiting current EU Commission-provided services (eHealth Digital Service
Infrastructure)

12. GOALS
• Facilitate the discovery/recruiting and onboarding of patients in clinical trials by providing
a procedure to evaluate inclusion/exclusion/randomization criteria and subsequent
follow-ups / healthcare encounters, and providing (anonymized) clinical data to research
• Global Record Locator Service
• Provide a way to reward patients for their participation (and creating a marketplace
where those reward can be exploited)
• Exploiting the naive blockchain case
• Define a provenance tracking for clinical data to be used in clinical trials
• Defining templates and storing it in the blockchain

13. PILLARS
• Healthcare data is NOT stored in the blockchain: data stays at the healthcare facility
• All the accesses are made using IHE/HL7 FHIR only: no need to implement yet another
standard (IHE ITI, and QRPH)
• Patient decides through an app the informed consent and she is followed during the
entire workflow. Consent is stored in the facility (BPPC)
• For each (anonymized?) data, a provenance record is tracked and stored in a private
blockchain

14. THE GOE
Technology already exists!
• Communication is done using IHE
• Public Ethereum / HL Fabric
• Data stays at the HPO, as well
consent(S)
• Marketplace with connectathon for
testing vendor’s façade
• Designed to work with NwHIN,
eHDSI, Trillium Bridge, EUPID,
Survivorship Passports, National
Health Systems (ELGA, NHS,
Gematik, Italian FSE)

15. THE GRAPEVINE
APP
• Patients register by visiting an Healthcare
Provider
• Patients are notified when a new CT is
submitted
• Patient gives consent for the evaluation of
incl/excl criteria
• GOE (and clinicians, depends) evaluates
onboarding
• Patients are notified and consent is obtained
and submitted to HPO
• Data matching clinical trial is collected and
returned to Pharma/PopHealth (GOE queries all
HPO where patients have registered)
• Further encounters are scheduled in the app
• Lifestyle data are obtained (upon permission)
from the sensors in the smartphone

16. PROVENANCE
TRACKING
• For each document, a provenance
record is evaluated (IHE mXDE, FHIR
Provenance) and stored in HL Fabric
on Azure (blockchain-as-a-service)
• Use of W3C PROV

17. THE PILOT STAGES
• Stage I: Deployments of the system in DE and AT pilot sites / establishment of the
technology / description in IHE format of the integration profiles, and relevant
connectathon testing (current stage)
• Stage II: Gather information from piloting with doctors and Pharma / definition of a
common framework of inclusion criteria / definition of a interface to report the clinical
documents, usability tests

18. THANK YOU FOR
YOUR ATTENTION!

19. BACKUP SLIDES: USE CASES

20. USE CASE: HEALTHCARE DATA EXCHANGE & ACCESS
Backbone
B
Backbone
A
Backbone
F
Backbone
C
Backbone
E
Backbone
D
Clinical Patient Data
Clinical Patient Data

21. 1. Pharma Request costs x Grapes/Patient
2. Patient receives 0,6x Grapes for giving Consent and providing Fitness Data
3. Healthcare Provider receives 0,2x Grapes/Patient for providing Clinical Data
4. Analytics Service Provider receives 0,2x Grapes/Patient for providing Service
USE CASE: HEALTHCARE DATA UTILIZATION
CLINICAL STUDIES
Healthcare
Provider
Pharma
Consent
Patient
Fitness Data (optional)
Data
Analytics
Request for Patient data

22. 1. Patient donates personal health data and gives consent
2. Teaching/Research Organization pays x Grapes/Data Set
3. Healthcare Provider receives x Grapes/Data Set
Healthcare
Provider
Patient
Consent
Fitness Data (optional)
Teaching &
Research
USE CASE: HEALTHCARE DATA UTILIZATION
TEACHING & RESEARCH

23. 1. PopHealth Request costs x Grapes/Patient
2. Patient receives 0,6x Grapes for giving Consent and providing Fitness Data
3. Healthcare Provider receives 0,2x Grapes/Patient for providing Clinical Data
4. Analytics Service Provider receives 0,2x Grapes/Patient for providing Services
USE CASE: HEALTHCARE DATA UTILIZATION
POPULATION HEALTH
Healthcare
Provider
Consent
Patient
Fitness Data (optional)
Data
Analytics
Request for Patient dataPopulation
Health

24. USE CASE: HEALTHCARE DATA UTILIZATION
APP DEVELOPMENT
Healthcare
Provider
Consent
Patient
Fitness Data (optional)
App
Developer
1. AppDev Request costs x Grapes/Data Set
2. Patient receives 0,8x Grapes for giving Consent and providing Fitness Data
3. Healthcare Provider receives 0,2x Grapes/Patient for providing Clinical Data

25. 1. Payor Request costs x Grapes/Patient
2. Patient receives x Grapes for providing Consent + Fitness Data
USE CASE: HEALTHCARE DATA UTILIZATION
FITNESS REWARDS
Patient
Consent
Fitness Data
Payor

26. 1. Patient pays x Grapes/Request
2. Healthcare Provider receives 0,2x Grapes/Request for providing Clinical Data
3. Expert Network receives 0,8x Grapes/Request for providing Expert Opinion
USE CASE: ACQUIRING MEDICAL SERVICES
EXPERT NETWORK
Healthcare
Provider
Request for Expert Opinion (incl.
Consent) Patient
Expert Opinion
Expert
Network

27. 1. Patient x Grapes/month for CM services
2. Healthcare Provider receives 0,1x Grapes/month for providing Clinical Data
3. Care Manager receives 0,9x Grapes/month for providing CM services
USE CASE: ACQUIRING MEDICAL SERVICES
CARE MANAGER
Healthcare
Provider
Patient
Consent
Fitness Data
Care
Manager