Healthcare Data Management using Domain Specific Languages for Metadata Management. - Splash2018 DSLDI Workshop
•Download as PPTX, PDF•
0 likes•65 views
A talk looking at Human factors of DSL Usage, tool support for DSL users, benefits for using DSLs. In essence an experience report on the usage of DSL's in the development of a metadata management toolkit, which focuses on DSL development in general
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Healthcare Data Management using Domain Specific Languages for Metadata Management. - Splash2018 DSLDI Workshop
Similar to Healthcare Data Management using Domain Specific Languages for Metadata Management. - Splash2018 DSLDI Workshop (20)
Recently uploaded
Recently uploaded (20)
Healthcare Data Management using Domain Specific Languages for Metadata Management. - Splash2018 DSLDI Workshop
- 1. Healthcare Data Management using Domain Specific Languages for Metadata Management David Milward This talk looks at : human factors of DSLs tool support for DSL users studies of usability and other benefits of DSLs experience reports of DSLs deployed in practice
- 2. Overview
- 5. • A data dictionary is not enough • A catalogue is not enough • The tools must be usable by domain experts. • There will be more models than you think
- 11. Within our language the prime artefacts are DataItems and Relationships, so it is essential to ensure that all relationships are valid, therefore we need a notion of referential integrity.
- 12. Referential Integrity is provided out of the box with Xtext, which in turn leverages the Eclipse Modelling Framework (EMF), which in turn has an API for validation of Ecore models.This can be accessed directly for other validation, and thus one can avoid complicated grammar rules – since DSL’s in Xtext are defined by grammar rules (similar to ANTLR)
- 14. Refines – the idea of can I use data item A instead of data item B. Example: Sex is classified in a number of ways in NHS datasets, for Genomics England the key ones are: 1. Phenotypic Sex - 2 Female 1 Male 9 Indeterminate 2. Person Stated Gender - 1 Male 2 Female 9 Indeterminate (Unable to be classified as either male or female) X Not Known (PERSON STATEDGENDER CODE not recorded) 3. Person Karyotypic Sex XY : XX : XO : XXY : XYY :XXX :XXYY : XXXY : : XXXX : other : unknown
- 22. Very common groovy ‘builder’ pattern used for building request object. This code is used behind the scenes to fetch details of data items, in particular regular expressions which are used in DataElement specification, the regular expressions are then used to generate “fake data”
Editor's Notes
- My name is David Milward, I'm a PHD(DPHIL) student at Oxford University Department of Computer Science, a rather ancient student - I previously worked in Data Interoperability for about 10 years prior, primarily for NATO. NATO an organization with a large number of members who all want to share data, that is to say they want to see everyone else's data, but they don't want anyone looking at there's....I've since worked for the last 5 years in the healthcare sector exploring new ways of managing and integrating datasets, some of which involve Domain Specific Languages, which is why am I am here talking....
- I’ve partitioned the talk into the following sections for clarity and reference. In fact I am going to be telling a story over the next 25 minutes, it starts in late 2013/2014 when I was a full-time DPhil (PHD) student at Oxford and I was asked to provide a DSL to represent the ISO11179 standard for metadata registries, specifically in connection with a project my supervisor was conducting at the Oxford Biomedical Research Centre. We submitted a paper to this same conference in 2015 called: “Domain-Specific Modelling for Clinical Research”, which my colleague (at the time) Dr Sayeed Shah presented. The Oxford BRC continued working with Genomics England until early 2016, at which point they asked myself and some colleagues to take over the work, since it was no longer deemed ‘research’, so we formed a small company to carry on this work with Genomics England and a number of other Healthcare Organizations, the core work has gone into a toolkit which I will give you a quick demonstration of at the end of this talk. The story is not JUST about Domain specific languages, it is a project that has used DSL’s and it is the documentation of that experience. We ended up using 3 DSL’s, 1 based on the Xtext workbench, and 2 as Groovy (internal) DSLs. I’m going to tell the story from the beginning to give context, and then move into cover the DSL’s in turn in more depth. Finally I will give a quick toolkit demonstration, showing how DSL’s can be used in Dataset validation.
- The original project was to integrate datasets from 5 different healthcare trusts. The approach was to write a small mini-language to try and capture the essence of ISO11179 – the standard for metadata registries. This has already been used in an exploratory project at Oxford, sponsored by Cancer Research UK, and had been used in the US for the CaCore (G. A. Komatsoulis, D. B. Warzel, F. W. Hartel, K. Shanbhag,et al. caCORE version 3: Implementation of a model driven, service-oriented architecture for semantic interoperability. Journal of Biomedical Informatics, 41(1):106–123, 2008.) Thus we were following up these lines of work. The initial problems were that the core meta-model defined in ISO11179 was internally inconsistent and impossible to implement fully. The first prototype resulted many data items having to be entered twice or 3 times, hence we trimmed it back to Iteration 1. At this point the team at Genomics England looked at our results and decided they wanted to sponsor the project forward, this time to integrate 10-12 different datasets. However the terminology was still difficult so we started from scratch.
- The problem: The left column showed the main artefacts used to express datasets using ISO11179 The middle column was our first iteration The RHS column was out second (successful) iteration. Names : Model Catalogue, Metadata Exchange, Metadata Registry, MML (Metadata Modelling Language), MDML (Metadata Management Language)
- By this point in time the metadata registry had morphed into the Model Catalogue. The results in the 2015 are listed as: A data dictionary is not enough. A simple, flat list of data definitions does not support re-use at scale: it requires the user to place all of the contextual information into the definition of each data item, and mitigates against the automatic generation and application of definitions. Instead, a compositional approach is required, in which data elements are defined in explicit context. A catalogue is not enough. The models in the catalogue must be linked to implementations, and to each other, with a considerable degree of automatic support. If the models are out of sync with the implementations, and with the data, then their value is sharply diminished. If you are going to manage data at scale, you need a data model-driven approach. The tools must be usable by domain experts. To have the processes of model creation and maintenance mediated by software engineers is problematic: there may be misunderstandings regarding interpretation, but—more importantly—there are not enough software engineers to go around. An appropriate user interface, that closely matches the intuition and expectations of domain experts, is essential. There will be more models than you think. Different models will be required for different types of implementation, and—in any research domain, at least—data models will be constantly evolving, with data being collected against different versions. Intelligent, automatic support is essential. The information content of precise data models is considerable, and there may be complex dependencies between data concepts and constraints. A considerable degree of automation is required if users are to cope with this complexity. =================================================
- The data standards being used in healthcare originate from different specialist areas, use different formats and have many overlaps, resulting in a number of different viewpoints over which standards are more or less useful. This list gives an overview of the main standards currently used in the UK NHS. Each standards has a different history, a different set of demands and a different ‘language’.
- A quick example would be the idea of pre-coordinated and post-coordinated terms in SNOMED CT.
- This is the kind of existing Dataset that needs to be managed. It is presented in a spreadsheet form, the headers provide the definition of the metamodel, which is then transformed into the MDML format. Example will be shown later on.
- Continuing the idea that Xtext builds on EMF, we are able out of the box to enforce referential integrity. After the first two iteration we made a detailed examination of what kind of language was needed, and we wrote this specification up using a formal language called Z. The Z specification allowed us to work out what was required in the initial language. Referential Integrity was required, as expressed in the snippet here.
- This
- Key Features Unique ID for a DataModel – built in with version and status Status relates to lifecycle – draft-finalized-superceded(deprecated) GUID – unique identifier for dataitem – e.g. status=draft 123123@0.01, or status=finalized 123123@1.00 Refines relates to the idea of can dataitem A be used in place of dataitem B e.g. sex. Phenotypic Sex - 2 Female 1 Male 9 Indeterminate Person Stated Gender - 1 Male 2 Female 9 Indeterminate (Unable to be classified as either male or female) X Not Known (PERSON STATED GENDER CODE not recorded) Person Karyotypic Sex XY XY XX XX XO XO XXY XXY XYY XYY XXX XXX XXYY XXYY XXXY XXXY XXXX XXXX other other unknown unknown
- So when we are mapping and transforming datasets refinement relationships can be defined. This idea has been removed from the latest versions, but may be re-introduced.
- Relationships can be varied, and can map between different elements or data items ExtensionItems are in effect pure “metadata” And enable transformations to work effectively – anything not expressible in the target dataset is stored in an ExtensionItem
- Status – refer to previous explanation Constraint – allow a) constraints upon element types – i.e. a DataType can be constrained by a regular expression b) A number of DataElements can be constrained as a group within a Datamodel
- You can also write this from a groovy script – see web page documentation at the end. Future work – to put a direct call into the metadata registry to get the item – i.e. within the DSL
- What is happening is that the item named is being searched for, an ID found and then a request made to the server and specifications are obtained.
- This is the fake data being generated from the previous DSL.