Researcher profile

Martin Chapman

Martin Chapman contributes to research discovery and scholarly infrastructure.

ResearcherAffiliation not importedOpen to collaborate

Trust snapshot

Quick read

Trust 13 - UnverifiedVerification L1Unclaimed author
2works
0followers
2topics
4close collaborators

Actions

Decide how to stay connected

Follow researcher0

Identity and collaboration

How to connect with this researcher

Claiming links this public author record to a researcher profile and unlocks direct collaboration workflows.

Log in to claim

Direct collaboration

Open a focused conversation when the fit is right

Claim this author entity first to unlock direct invitations.

Research graph

See the researcher in context

Open full explorer

Inspect adjacent work, topics, institutions and collaborators without jumping out to a separate graph page.

Building this graph slice

BZPEER is loading the nearby papers, people, topics and institutions for this page.

Published work

2 published item(s)

preprint2020arXiv

A semi-autonomous approach to connecting proprietary EHR standards to FHIR

HL7's Fast Healthcare Interoperability Resources (FHIR) standard is designed to provide a consistent way in which to represent and exchange healthcare data, such as electronic health records (EHRs). SMART--on--FHIR (SoF) technology uses this standard to augment existing healthcare data systems with a standard FHIR interface. While this is an important goal, little attention has been paid to developing mechanisms that convert EHR data structured using proprietary schema to the FHIR standard, in order to be served by such an interface. In this paper, a formal process is proposed that both identifies a set of FHIR resources that best capture the elements of an EHR, and transitions the contents of that EHR to FHIR, with a view to supporting the operation of SoF containers, and the wider interoperability of health records with the FHIR standard. This process relies on a number of techniques that enable us to understand when two terms are equivalent, in particular a set of similarity metrics, which are combined along with a series of parameters in order to enable the approach to be tuned to the different EHR standards encountered. Thus, when realised in software, the translation process is semi-autonomous, requiring only the specification of these parameters before performing an arbitrary number of future conversions. The approach is demonstrated by utilising it as part of the CONSULT project, a wider decision support system that aims to provide intelligent decision support for stroke patients.

preprint2020arXiv

Non-repudiable provenance for clinical decision support systems

Provenance templates are now a recognised methodology for the construction of data provenance records. Each template defines the provenance of a domain-specific action in abstract form, which may then be instantiated as required by a single call to the provenance template service. As data reliability and trustworthiness becomes a critical issue in an increasing number of domains, there is a corresponding need to ensure that the provenance of that data is non-repudiable. In this paper we contribute two new, complementary modules to our template model and implementation to produce non-repudiable data provenance. The first, a module that traces the operation of the provenance template service itself, and records a provenance trace of the construction of an object-level document, at the level of individual service calls. The second, a non-repudiation module that generates evidence for the data recorded about each call, annotates the service trace accordingly, and submits a representation of that evidence to a provider-agnostic notary service. We evaluate the applicability of our approach in the context of a clinical decision support system. We first define a policy to ensure the non-repudiation of evidence with respect to a security threat analysis in order to demonstrate the suitability of our solution. We then select three use cases from within a particular system, Consult, with contrasting data provenance recording requirements and analyse the subsequent performance of our prototype implementation against three different notary providers.