Information model manager

From Discovery Data Service
Jump to navigation Jump to search

The information model manager (IM manager) is a multi modular web application designed to provide a view of the common information model, and to support the authoring of the content of the model.

The application is used in one of three modes:

  1. IM Viewer. This is a public facing user interface that provides views of the model structure and content. This is limited to browsing and cut and paste, but as the model content is partly licensed by external parties, only a limited amount of download is supported.
  2. IM Access. This includes the viewer and also allows download of artefacts supported by the model. For example, users can download individual value sets or query definitions, the entire library of value sets, or even the full ontology itself. This requires authentication against a user account as some content of the information model is licensed by third parties (e.g. Snomed-CT).
  3. IM manager. This incorporates the viewers and access but has full support for the ontology authoring and reasoning. In addition to the standard "views" there are also specialised views that provide purpose specific view components not needed in the viewer.

The application does not support query editing, or report management. However, the components used by the IM application are used within the Discovery explorer, Discovery analyser and Discovery data sharing manager applications. Other applications are able to access the information model via the externally facing APIs. For each interface between the Discovery applications and the information model, there is an equivalent (or indeed the same) externally facing API.

The API catalogue is documented elsewhere on this wiki and accessed via the Endeavour-Discovery GitHub

Conventions and terms in use

Approach to the specification

This specification describes the functionality of the various modules from the perspective of a user accessing the application.

The general approach taken is to group by a page hierarchy, and group functionality, but to describe each page or functional requirement from the perspective of a user question or a user's intended task (use case). User examples are included in coloured text boxes in the first person as follows:

Text in this colour is me, as a user, describing what I want to do or a question I need to answer

Terms in use

  • Page view Refers to the purpose and layout of a page as a whole
  • Section view Refers to a particular view within a section of a page

Access to the IM manager

Access to the IM manager by users is in line with the 3 level approach as described by the article on authentication and authorisation. Identify, authentication and authorisation are determined by the 3 modes as follows:

Log in options.jpg

I wish to quickly access information about the data held in discovery

I would like to download the value sets and the data model

I need to map some system specific codes and terms to the model and create some axioms and class expressions along the way

The 3 application modes map to the levels of identity, authentication and authorisation as follows:

Mode Identity Authentication Authorisation Description and permissions
IM Viewer Level 0 Anononymous Level 0 Level 1


Role = general public

View and limited cut and paste

Any user can use the IM viewer subject to accepting the sub- license conditions
IM Access Level 2

User account

Level 1

Single factor

Level 1


Role = Informatician

Account allocated with community level identity management (e.g. email request)

User is covered by NHS license arrangements for third party artefacts. (Discovery artefacts are openly available).

May download all artefacts at page or item level.

IM manager Level 2

user account

Level 1

Single factor

Level 2


RBAC Role = editor

Account allocated with organisation level identify management. Users RBAC role allowing authoring of value sets and query.

Concept authoring at a modular level controlled by ABAC policy

IM Manager application top bar

Within every page, the top bar provides information about the page view for that page as well as general information about the application or the user themselves. The user may access these either for information or in order to change the layout or type of page content.

The following information may be displayed directly or accessed via user selection;

User details, including role and profile details

I am not sure that I am fully logged in, or whether I am in the right role at the moment, and wish to view or amend my contact details

Selection provides a brief summary of the profile and a link to the user manager module, the level of access to which is determined by my authorisation level

About the application, including links to Github or the Wiki

I wish to explore the technical details further, including the source code for this application, what the version is, and background to Discovery

Selection shows this information and enables navigation to the Endeavour Discovery GitHib or the Discovery Wiki

Page view

I am accessing the overview page of the data model which is a simple list categorised under headings. I now wish to understand the definitions of concepts held within the Discovery information model and would like to examine those.

Selection of drop down enables a change of page view. The application remembers the last view for the user when revisiting this page (unless the context has changed) and when subsequently accessing the application next time.

View Filters

I am navigating the semantic ontology and particularly interested in the things that are properties, attributes and relationships. I am currently getting huge lists of classes and want to narrow this down.

On selection the user can view and change filter settings as per the description below around parameters

Typically a user may have a default view for most pages and have access to a number of pre-configured named filters (e.g.filtering of data properties/ relationships or object properties)

I am confused by the tree on the left that has two ways of navigating and want only children of the the data model as organised according to subject.

The user should be able to create and add a new filter.

Application home page

I have been looking at the value sets and want to go quickly to another module within the IM viewer. Not sure which module I want to visit so best to go to the home page

Home page view

The application home page view informs the user of the modules they have access to, currently these being:

  1. Data model view
  2. Semantic ontology view
  3. Value set views
  4. Data set views
  5. Data Map view

Data model viewer

The data model viewer allows a user to navigate and download the content of the Discovery core health data model which is a logical, machine readable model of the data as held in the health records. The model forms part of the ontology, and links directly to the value sets and semantic ontology. In common with the ontology as a whole, all items in the data model are either classes or properties. Internally they are modelled as axioms using the OWL2 language.

Viewers of the data model are varied. They will have different experiences and skills and are using the viewer for a variety of purposes.

These skills can be categorised. Viewers may also be navigating the model with different tasks in mind and these too may be categorised. Therefore the views of the model take account of both the different skills and different use cases.

The data model viewer has a set of view types. These views operate at the level of the page. i.e. indicate the type of view and the type of view can be changed by the user via the application top bar.

Data model overview

Overview of record entity types

What sort of structure does a Discovery record have? I just want a quick list but categorised in some way e.g. whether about the patient, things that have been observed or done for the patient, and what type of interactions with the health service are recorded. I only have a minute. I am a clinician interested in records but I am no expert.

This type of view provides a brief overview of the structure of the records in the form of data entities. (aka tables or resources). They are categorised by general subject matter (a opposed to a class based view).

Selection of any one of the data entities will change the page view to the data model navigator and show more information about the entity.

Data model tree view

DM Hierarchy view

The ontology classifies the data model in the same way as i classifies the semantic ontology. Classes naturally fit into hierarchies.

Subclass hierarchies in Discovery support subclass intersections, or multi-inheritance. This abiligy enables different approaches to be taken to organising a tree. For example, the data model can be classified by purpose, or could be classified according to property inheritance. In fact both approaches can be used, leaving it to the user to decide. The following two question:

I would like to see to explore the data model by subject category and examine the relationships between one entity and another, as well as the properties within them

What is the rationale behind this entity and the attributes for this entity? What is the relationship between this entity and other entities? Does this entity have subtypes which are more specialised? Does this entity have attributes similar to other entities? What values can the attributes have?

Core properties, extended properties, relationships

At an ontological level, classes have data properties (whose values are literals) and object properties whose values are objects (which are labelled as instances of concept classes). Object properties in a data model may relate two data model entities to each other. How objects relate to each other is critical to the understanding of a data model. In the same was as relational databases use foreign keys, the ontology uses relationship types. Relationship types are object properties whose target value is another data model entity.

I note that an A&E attendance is a type of encounter, I see that it links to the provider that is data controller, the patient who is the subject of the encounter. I also note that the attendance has a sub-encounter for the triage process. In addition it contains sections (headings) and linked events (such as observations.

I would like to view the relationships and navigate to see what they are

To fulfil this requirement, the data model screen has a relationship view

Properties of DM entties

As well as relationships, a data model entity has properties which may be data or object properties. From a technical viewpoint it is necessary to know the identifiers of the data model class, its properties, and the value ranges of the properties. A graph view can be somewhat limited and more detail is needed.

Some properties are core to the business definition of the entity (i.e. would be normally expected to be mandatory) whereas other properties are optional. In some entities, there are many optional properties, thus a means of differentiating the two is required

Ontology viewer

The user - who is an informatician has a goal to understand how concepts have been modelled and which concepts exist so that they can:

  1. identity missing concepts
  2. identity inconsistency
  3. identify duplication
  4. identity inaccuracy

Functionality of the ontology viewer consists of :

  • Search for a concept by name or iri
  • View a concept in it's hierarchy showing what is above it, what sits next to it and what sits directly below it - allows the user to determine if any concepts are missing from the hierarchy, if the hierarchy looks inaccurate suggesting a misclassification of concept(s)
  • View what concepts reference the current one - allows the user to look for inconsistencies and duplication of concepts
  • View attributes attached to the current concept - allows the user to see if anything is missing or if anything is present that does not belong or any inconsistencies compared to other concepts
  • View data models that reference the current concept - allows user to see if the concept is being used in a way that fits with the concept's meaning
  • View underlying Discovery syntax - for an expert user to quickly understand how a concept is put together, potentially they could use the definition as a template to allow them to understand how to model a similar novel concept in Discovery