CD2H gitForager

openhealthcare/django-openehr

Name: django-openehr

Owner: Open Health Care

Description: experimental django models based on openehr archetypes

Created: 2018-01-17 17:23:24.0

Updated: 2018-03-16 12:25:09.0

Pushed: 2018-03-16 12:25:08.0

Homepage: null

Size: 113

Language: Python

GitHub Committers

User	Most Recent Commit	# Commits

Other Committers

User	Email	Most Recent Commit	# Commits

README

django-openehr

Experimental | Not officially supported by OHCUK

Experimental Django models based on openEHR archetypes and distributed as a Python Package on PyPi, with an accompanying demo Django application, showing the implementation of a single openEHR Template as a Django Form composed of data fields from the correct underlying openEHR Archetypes, as defined in the Template on the UK Apperta Clinical Knowledge Manager

The intentions of the experiment are:

to learn more about the internal structure of openEHR by creating a 'toy' set of models using these archetypes.
to explore the feasibility of 'misusing' the freely published openEHR archetypes as a 'source of clinical modelling truth' when data-modelling a web application in Django (or any other web framework), as opposed to using openEHR as a technical layer in the intended manner.
to understand the minimum range of archetypes required to build a proof of concept EHR app.

Templates included (in the demo app)

Archetypes included

all data from each CKM archetype has been retained as comments in the respective Django model file

Reference Model artefacts converted

Method/Approach

For this experiment/proof of concept, we have attempted to emulate in Django the two-level clinical modelling paradigm of openEHR (archetypes and templates), a paradigm which is also shared by other clinical modelling technologies such as FHIR (resources and profiles)
openEHR Archetypes have been recreated as Django models. In Django (as in many web frameworks), models are Classes, instances of which can be assigned data attributes, and these data attributes for a given instance map to a given row in a database table. Django contains an object-relational mapper (ORM) which handles this abstraction automatically, and numerous convenience methods which simplify access to related objects through foreign key or join-table relationships.
openEHR Templates have been rendered as Django Forms, which form the second layer of our modelling tooling, allowing constraint and specialisation of our Django model (= our archetype)
Practically, in the absence of an automatable mechanism for creating Django forms from openEHR archetypes, we simply copied and pasted the text from the 'Data' tab of the UK openEHR Clinical Knowledge Manager for each archetype into a text editor. We then reformatted the archetype into a Django model (or model_s_), mapping field types, validations, maxima and minima into their Django idiomatic equivalents. We kept as much contextual information as possible in #comment form.
Models were quite large and therefore for better readbility and also in an effort to optimise the re-use potential of the models, they have been separated out from models.py into individual files under the /models/ directory, importable as a module because of the __init__.py containing an __all__ list.
openEHR implementations tend to store data in documents rather than in relational tables, hence it's possible that in the conversion of Archetypes to Django models we will encounter modelled entities which are impractical to model in a relational fashion, however so far we've been able to model most things that made sense to model.

Upstream Issues with Archetypes

Where issues have arisen regarding upstream archetypes or templates, I've created a GitHub issue in this repo as placeholder/record, and then I've passed the issue back to the UK CKM via it's own internal Change Request method.

Installation

Installing the package

This package has been designed to be a reusable group of clinical models drawn from a canonical source (UK CKM), which can be used in other applications.
To use it in your own Django project or app, you need to install the package via the command line/terminal:
```
install django_openehr
```
or

add django_openehr to your requirements.txt file, and then run

install -r requirements.txt

Adding these models to an existing Django application

you may need to adapt these instructions to the specifics of your Django application, since we haven't tested every use-case. If you have problems please feel free to raise an Issue about it, we may be able to help.
add django_openehr to the INSTALLED_APPS list in settings.py
make the database migrations
```
on manage.py makemigrations
```
apply the migrations
```
on manage.py migrate
```
register the models with the Django Admin if you want to be able to manipulate these models in the Admin view. You can see an example of how to do this here
start the development server
```
on manage.py runserver
```

Interacting with the models using the Django shell

install as per above instructions, including migration steps
invoke the Django shell
```
on manage.py shell
```
import the models
```
 django_openehr import models
```
you can then interact with the models and the data in your database using the standard DJango ORM API, eg:
```
models.PersonName.objects.first().given_name
cus'
```

Contributing to this project

We welcome contributions from the community, and are happy to consider pull requests for bugfixes, optimisations and new archetypes.
For new Archetype contributions, please follow the one-model-per-file pattern used throughout this package. We accept that this is not traditionally a Django idiom (Rails is all over it though :-) ), but it helps with organising the models, which can become very large and would be unwieldy in a single file.
Please also consider updating the forms and details views in the companion Demo Application with your new models
We welcome discussion regarding this package in the Issues

This work is supported by the National Institutes of Health's National Center for Advancing Translational Sciences, Grant Number U24TR002306. This work is solely the responsibility of the creators and does not necessarily represent the official views of the National Institutes of Health.