Research

Choice of framework

Two main frameworks that we choose are AngularJs and ReactJs since they are both popular ones with sufficent tutorials and resources online. AngularJs is an open source javascript library maintained by Google aiming to use MVC mode to grease the development of online application.

ReactJs is a library developed by Facebook. Because the complexity of the code during development stage, MVC is becoming more and more complicated to use. Therefore, ReactJs is using virtual DOM to decrease the calling of DOM which is expensive to call. This became an advantage for ReactJs to run much faster than AngularJs if it comes to a complex backend calculation. It makes the calculation of DOM diff more efficient.

MVC Architecture View

Based on the understanding of two libraries, we decided to use ReactJs as our developing tool since we are building a form generator and the main focus will be on backend constructing templates and pasing them. We will need a ‘lighter’ framework to run the webapp smoother.

Initial Decision

Initially we decided to use the platform called electrode consists of nodejs and ReactJs and other libraries and build-ins. One of the main reason for choosing this framework is that it combines two main JavaScript frameworks like NodeJS and ReactJs but also has other libraries for the other team to use. One of the main advantage of using electrode is its consistent structure for building and rendering scalable applications.In the beginning, other teams working with us on this PEACH project have agreed to use Electrode.io to build the React.Js components for the system.

Drawbacks

One of the biggest problem we encountered during the development is the lack of resources online. This is because Electrode.io is a relatively new platform,that is recently launched in 2016. Furthermore, upon encountering problems, there are not many help online to help us. Hence, our learning curve became increasingly steep as we have to both learn about how React.Js works and how Electrode works. In addition to that, there are limited choices of libraries available to help us deal with the backend side of this project.

Final Framework Decision

Despite our effort and hard work to understand Electrode.io, we still weren’t able to progress in the first two weeks of development cycle. With careful considerations, we decided to use React.Js instead of electrode. We realised that even though Electrode.io provides a framework to build React.Js applications, its complexity outweighs its advantages. Taking into account the limited time of this project, we made a reasonable decision to proceed using React.Js instead. We further discussed with other teams to ensure interoperability of the system. We found out that other teams were struggling the same way and decided to use React.Js instead.

Advantage and disadvantage of ReactJs

Advantage	Disadvantage
Performance gain and flexibility.	Steep learning curve
React the DOM only re-renders the specified components and hence avoid the expensive DOM manipulation	It is still a relatively new framework, there are not that many open sources contributions as compared to older framework like AngularJs
Readable and maintainable code through the use of JSX syntax	Requires basic knowledge of JSX and ES6
Can be easily integrated with other framework such as AngularJs or Node.Js because ReactJs serves as the view layer in MVC backbone	ReactJs is designed for developer User Interface, a lot of additional libraries are required to develop the back-end part of this project

Additional Libraries, APIs and software components

Tools	Functionalities
Firebase	A real time-database system which provides API to allow developers to synchronize and store data across multiple clients. It is used in our application for the secure login to our system.
Zepto	Minimalist JavaScript library for modern browser that is compatible with jQuery API
Babel	A configurable transpiler, a compiler which translates JavaScript ECMAScript 6 to ECMAScript 5 that can run in all browsers
Webpack	A module bundler used to put all assets including images, CSS and Javascript together in a dependency graph
ClassName	JavaScript libraries used for joining classNames together in order to maintain the change of form state during the form rendering.
ReactBootstrap	Free, open-source front-end web frameworks for designing the User Interface built for React.
AdminLTE	A styled-components library providing React front-end reusable Components

Back-end Research : OpenEHR

openEHR overview

“openEHR is a virtual community working on means of turning health data from the physical form into electronic form and ensuring universal interoperability among all forms of electronic data. The primary focus of its endeavour is on electronic health records (EHR) and related systems.” [1]

OpenEHR architecture consists of several core artefacts:

Reference model

This is an underlying component that defines ways in which data obeying to openEHR standards is stored, created and processed. This artefact can be understood as an openEHR-specific information model, that determines all possible data. All data points, groups and sets in openEHR derive from reference model.

Overall Structure of openEHR Artefacts

Archetypes

Archetype is a collection of data points that are related to a particular entity. If we regard reference model as a large collection of data points, than we could say that archetypes impose restrictions on the model, so that only relevant points are available. This collection of data point is called a data group. An example here would be “blood pressure” data group, that can have “systolic” and “diastolic” as data points. [1]

Templates

Both data points and groups are very generic and not related to any particular medical event or document. In order to implement this, event-specific data sets are created. They serve as a basis for software components adhering to openEHR standards. Each template is composed from a number of archetypes, but data points within each archetype can be further restricted so that the template provides only relevant information to a particular case. For instance, a template that includes “blood pressure” archetype is constructed. If we are only interested in systolic blood pressure, than “diastolic” data point can be restricted and it will not be displayed in a final software component. An example of entities for which templates can be created include “Health Risk Assessment form” and “GP encounter log”.[2]

Software components

Finally, templates can be used to generate software components that will be used in a medical system. The components will contain representation of data points that were included in the template. Possible components include input and output forms, APIs, dashboards.

More on archetypes and templates

Relationship between data in reference model and archetype domain

As it was outlined in the previous section, reference model is a huge collection of data points that can be combined in a variety of ways, creating data instances. On the diagram below, they are represented as a larger ellipse - “All possible data instances”. However, only a relatively small proportion of these combinations can be practically applied - “Meaningful data”. To represent this subset of data that can potentially be used, openEHR provides archetypes.

Archetypes are created by picking out useful in some context data points from reference model and thus creating a data group. This approach enables the same information model to be reused to create a large range of different archetypes. Hence, a full subset of “Meaningful data” can be represented.

In terms of physical representation, archetypes can be regarded as instances of Archetype Object Model, which provides an overall structure for archetypes[3]. There are several languages, in which archetypes can be implemented, however the most commonly used one is Archetype Definition Language (ADL). [4]

Structure of an actual "Blood Pressure" archetype. Note data points, including "Systolic" and "Diastolic"

Everyone can create their own archetypes based on reference model. However, already exists an Archetype Library, which is a repository of the most commonly used archetypes. This saves time and resources that could would be needed to create each archetype for every new system and facilitates data interpolation.

Templates is, essentially, a collection of archetypes that are suitable to describe a certain event or a document. However, template is not simply a composition of archetypes. It determine, which data points from archetypes will be included and even set additional constraints on them (e.g. that “systolic” field cannot be a negative number). Furthermore, some fields can be made mandatory for user to fill in.[2]

An intermediate step between a template and a software component is an operational template (OPT). There is a number of human languages, in which OPTs can be expressed, thus allowing for more flexibility of development process. OPT is a file with which programmers work directly when building software components.[5]

Benefits of openEHR

One underlying information model

Unlike in a traditional software development approach, reference model of openEHR is shared across all application that are based on openEHR architecture. This massively simplifies the process of data migration between different versions of applications and eliminates the cost of information model development.[4]

Platform independence

OpenEHR approach implies that data models are created independently of a particular implementation technique that was chosen for a software application. Data models are only dependant on the reference model, and thus are platform independent.[4]

Convenience for medical specialists

openEHR project, it is possible for medical specialists to define data models they need without any consultation with IT specialists. This is done through archetype and template generation. Furthermore, Archetype Library already provides a comprehensive set of archetypes that can be used in various medical system. This significantly reduces time spent on data definition.

Data interpolability

As all archetypes and templates are based on the same information model, data migration, which used to be a major expense, is not an issue any more. With openEHR data can freely move between various systems and medical institutions. In addition, Archetype Query Language provides a standard way to fetch data from openEHR repositories.[6]

Ability to adapt to change

All the points described above imply the main general advantage of openEHR approach - in case of changes that inevitably take place over time, the system will be able to preserve its consistency. This includes data migration, change in data models, system updates, and many other.

Weaknesses of the approach

A disadvantage of openEHR approach that our team identified is dependence on a particular reference model. Is a need for a more extensible list of data points arises, it will take a long time for the model to extended because typically it is done through a consultation with a broad range of medical specialists. Thus, openEHR could potentially be slow to adapt to a certain type of changes to requirements for medical systems.

Conclusion

Overall, openEHR is a great approach to building medical systems. It allows for a large amount of flexibility of both development and usage stages. It also has a number of valuable benefits, such a easier involvement for medical specialists and better data interpolation. The of issue of dependence on one reference model is not likely to cause complications due to an extensive nature of the model.

Back-end Research : EHRScape

As informed by our client, we are going to use Ehrscape temporarily since the formal backend is still being developed. However, there will be the exact API so that we don’t have to change too many lines of code even if the backend changes.[1]

So we will be using Ehrscape throughout the development. Ehrscape is a backend which allows us to get access to the database using official APIs. It is based on OpenEHR. Users can get access to patient details by using predifined ehrID. It also allows us to create new patients and input his details into the system. The API will be used inside javascript code so that it can be related to our front end as well.[3,4]

List of API Calls	Description
POST/COMPOSITION	Stores the form composition to EHRScape backend
GET /template/{templateId}	Fetch template from EHRScape Backend to be rendered

Examples of Composition POST


{
    "ctx/language": "en",
    "ctx/territory": "GB",
    "ctx/composer_name": "Dr Navin",
    "ctx/time": "2017-02-19T16:31:27.318Z",
    "ctx/id_namespace": "nhs.ucl",
    "ctx/id_scheme": "nhs.ucl",
     "ctx/health_care_facility|name": "UCLH",
    "ctx/health_care_facility|id": "9091",   "peach_diagnosis/problem_diagnosis:0/problem_diagnosis_name": "Problem/Diagnosis name 2",
    "peach_diagnosis/problem_diagnosis:0/date_time_of_onset": "2017-02-19T16:31:27.318Z",
    "peach_diagnosis/problem_diagnosis:0/severity|code": "someCode",
    "peach_diagnosis/problem_diagnosis:0/severity|value": "SomeValue",
    "peach_diagnosis/problem_diagnosis:0/severity|terminology": "someTerminology"
}

Summary of final decision

In conclusion, we are using React libraries to develop the front-end of the system and EHRScape for the backend of the system. React enables the use of JSX ( JavaScript XML) to improve the readability of our code for future development. As part of our main requirements, we need to produce clean code with extensive documentations for future development and ensuring appropriate comments are provided.React also provides a more efficient way of updating the view in web application through its virtual-dom. EHRScape backend allows our system to parse an .opt template and return a JSON object associated with the template. Our form builder parses this JSON object and renders a form that enables customisation. Our form is built on the top of OpenEHR guidelines of storing medical data to ensures efficient transfer of patients’ data and maintain data integrity.

References

Heard, S. and Beale, T. (2016) What is openEHR? Available at: http://www.openehr.org/what_is_openehr (Accessed: 10 December 2016).
Falkman, D. (2015) MVC Frameworks for Building PHP Web Applications. Available at: https://www.lynda.com/CakePHP-tutorials/MVC-Frameworks-Building-PHP-Web-Applications/315196-2.html (Accessed: 12 December 2016).
The openEHR Foundation (2003) OpenEHR architecture overview. Available at: (Accessed: 2 December 2016). http://www.openehr.org/releases/BASE/latest/docs/architecture_overview/architecture_overview.html
The openEHR Foundation (2014) Archetype technology overview. Available at:http://www.openehr.org/releases/AM/latest/docs/Overview/Overview.html (Accessed: 2 December 2016)
"Date And Time Strings (Javascript)". Msdn.microsoft.com. N.p., 2017. Web. 24 Apr. 2017.
Davis, Ewan. "Openehr Intro For Developers". Code4health.org. N.p., 2017. Web. 24 Apr. 2017.
Freshehr/Postman-Ehrscape". GitHub. N.p., 2017. Web. 24 Apr. 2017.
Sam Heard, Thomas Beale. "Openehr - Working With Templates". Openehr.org. N.p., 2017. Web. 24 Apr. 2017.
Heard, S. and Beale, T. (2016) What is openEHR? Available at:http://www.openehr.org/what_is_openehr (Accessed: 5 December 2016).
Operational template (OPT2) specification (2015)http://www.openehr.org/releases/AM/latest/docs/OPT2/OPT2.html (Accessed: 12 November 2016).
Heard, S. and Beale, T. (2016) Archetype Object Model. Available at: http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html(Accessed: 7 December 2016).
Heard, S. and Beale, T. (2016) Archetype Definition Language. Available at: http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html (Accessed: 9 December 2016).
Heard, S. and Beale, T. (2016) Working with Templates. Available at: http://www.openehr.org/downloads/ADLworkbench/working_with_templates (Accessed: 4 December 2016).
Heard, S. and Beale, T. (2016) Archetype Query Language. Available at: http://www.openehr.org/releases/QUERY/latest/docs/AQL/AQL.html (Accessed: 4 December 2016).
Advantages and Disadvantages of ReactJs. Available at:http://www.pro-tekconsulting.com/blog/advantages-disadvantages-of-react-js/(Accessed: 20 April 2017).