Roadmap of the openEHR Java project

Owned by Rong Chen
Last updated: 24-Jul-2019 by Jan MewesVersion comment
3 min read

The Road Map of the openEHR Java Reference Implementation Project

Purpose

This document provides technical description of the openEHR Java Reference Implementation Project. It lists all the existing components already provided by the Java project and their status for new comers to the Java project can get a quick impression on what the Java project can actually provide. It also informs about up-coming components to plan future development and coordinate possible collaborations. Note that components marked with "*" are currently not available from the Java project.

Related Documents

  1. The openEHR Architecture Overview
  2. The Mission Statement of the Java project.
  3. The openEHR Java Implementation Technology Specification

Overview

This road-map lists all the components that are necessary to build a complete EHR system. As convention, these components are categorized into three principal layers - Domain, Persistence and Presentation. Since openEHR systems are based on two-level model approach, the Domain Layer gets more complicated than that of any conventional Enterprise Applications. Instead of being hard-coded into software artifacts, domain models are expressed in the form of the Archetype Model.

Tools are listed separately since they don't belong to any specific layer. They can be used as stand-alone applications or as part of the larger system.

Domain Layer

Kernel Components

  1. openEHR RM Core implements openEHR Reference Information Model Common, Support, Data Types, Data Structures specifications
  2. openEHR RM Domain implements openEHR Reference Information Model EHR, Demographics, EHR Extract, Messaging specifications
  3. openEHR AOM implements openEHR Archetype Object Model specification
  4. openEHR AP implements openEHR Archetype Model - openEHR Archetype Profile

Service Components (star)

Implementation of up-coming services components. Some of the key components are:

  1. EHR Service implementation of EHR Service Model for high level EHR object storage and retrieval
  2. Demographic Service for high level Demographic object storage and retrieval
  3. Archetype Service minimal feature includes storage, retrieval and versioning of archetypes
  4. Terminology Service * a minimal openEHR terminology service necessary for the kernel to work properly - the initial coding was done as part of the parser component and it should be extracted as standard alone component. * a generic terminology service that can serve different international terminologies will be required in full-blown systems
  5. Query Service is a generic data retrieval service for fine-grained queries

Wrappers (star)

Wrappers are essentially Data Transfer Objects that transfer data before different layers and have little logic besides getters and setters. This will fulfill the need for missing direct setters of attributes in immutable RM classes which are required for certain type of OR mapping. * Wrappers can group low level RM objects into coarse-grained objects to facilitate data transfer and mappings.

Persistence Layer (star)

This layer provides generic storage and retrieval service for high level domain objects - EHRs or Demographics. The implementations of this layer will ideally be accessed through well-defined common interface, e.g. Data Access Objects to hide implementation details. Different flavor of the implementations should be supported.

  1. DAO interfaces these are interfaces for CRUD (Create/Read/Update/Delete) operations on high level domain objects, e.g. EHR Composition. These interfaces should be implemented by concrete persistence components
  2. Hibernate 2 Implementation this is an existing components implements the DAOs by OR Mapping tool Hibernate 2
  3. Hibernate 3 Implementation this components implements the DAOs by OR Mapping tool Hibernate 3
  4. OODB implementation is based on Object Oriented Database

Presentation Layer (star)

Components in this layer presents data to the user and intercept data entry from the user

  1. Screen Form Generator this component generates GUI screen forms based on the semantics in the Templates and Archetypes
  2. Form Validator this components provides user data entry validation based on constraints defined by the Archetypes. It is required to work closely with the Kernel component for validation and provide meaningful error message for the end user.

Tools

  1. ADL Parser this component implements the ADL 1.4 specification. It parse an Archetype in ADL format and produces its object form in AOM
  2. Archetype Editor this is a GUI based Archtype authoring application built on top of the Java components
  3. Archetype Validator (star) this component provides validation of Archetypes in AOM format against targeting Reference Model, e.g. correctness of names of the classes and attributes, and the semantics in the constraints, e.g. check the validity of an ArchetypeInternalReference
  4. ADL Serializer this component provides conversion of Archetypes from object form to serialized text form in ADL format