Project Register
Introduction
This page is a working document describing and prioritising existing and future openEHR.projects. An initial attempt at prioritisation has been made, but this would need to be properly reviewed within a funding framework.
Project Descriptions
Area |
Name |
Priority |
Description |
Objective |
Work estimate |
---|---|---|---|---|---|
|
|
|
PLATFORM SPECIFICATIONS |
|
|
Information specifications |
Release 1.0.3 |
+++ |
Ongoing maintenance based on CRs and Architecture Review Board consideration. |
Publication of release 1.0.3 |
|
|
openEHR support terminology |
|
Upgrade the openEHR support vocabulary to a more usable XML format, and add translations. |
A single openEHR terminology that is used by all openEHR implementations. |
|
Knowledge Specifications |
Draft of ADL/AOM 1.5 |
++++ |
Design and implementation testing of ADL 1.5 and AOM 2.1 with capability developed in archetype parsers, authoring tools and CKM to ensure implementation. These specifications along with the template object model are key to the next generation tooling of openEHR, which will integrate archetypes, templates and terminology, providing a computational basis for single-source model-based development of messages, documents, programming components. See Project page. |
Integrated single formalism for all archetypes and templates; including several semantic improvements needed by implementation. |
|
|
Draft release of the Template Model, including operational termplates. |
++++ |
Design and implementation testing of the Template Object Model supporting ADL 1.5. Includes a model for 'operational templates' which describes the standalone operational form of a template due to evaluating a Template Definition against the Archetype repository and terminology. Operational Templates are the close-to runtime form of a template, and are also the basis for creating Template Data Schemas (TDSs). |
Standardised form of operational template, the basis for all implementation transforms. |
|
|
Knowledge Artefact Governance Guide |
+++ |
A guide to the identification and ongoing management of Archetypes, Templates and Terminology reference sets. |
Coherent and reliable publication and reuse complimentary sets of artefacts. |
|
|
|
|
|
|
|
Security |
Access control specification |
+ |
A new access control specification will be added to the openEHR Reference Model to provide for the the CEN EN13606-4 standard for role-based access control for health information. The current release of the RM is already designed to accept a model of access control in a plug-in fashion. This will enable the addition of other models, including more complex non-role-based standards in the future. |
Plugin access control modules that support different national and international requirements |
|
Query specifications |
AQL |
++ |
Continue development of query language. Investigate convergence with Sparql and other web 2.0 query languages. |
Portable EHR data query language. |
|
|
A-Path |
++ |
Continue development of the A-Path specification. |
Support for predicate logic statements in archetypes; data query language. |
|
Information & knowledge Services |
vEHR - Virtual EHR Service |
+++ |
The virtual EHR is an application interface that provides access to all back-end services, as well as secure session management, without the application programmer having to know the details. |
|
|
|
EHR Service |
++ |
This service is a coarse-grained model of EHR access, at the level of Compositions and other top-level objects of the EHR. It supports Contribution committal, query-based retrieval and fast index-based retrieval. |
|
|
|
EHR / Subject Index Service |
++ |
This is a simple service providing a cross-reference between subject identifiers and EHR identifiers. It can be used to match a subject based on one or more identifiers, and find EHRs created for them. |
|
|
|
Archetype service |
+++ |
Service providing access to archetypes within operational systems. |
|
|
|
Terminology Refset Service |
+++ |
This service provides access to versioned terminology subsets, expressed in the form of dynamic queries against terminologies such as Snomed CT, ICDx etc. |
|
|
Business Services |
Instruction index |
++ |
Additions to the EHR Information Model will describe a model of Instruction / Action threads. In EHR data, this allows an Instruction and all Actions that have occurred as a result to be 'threaded' together and seen as a history of order + actions, enabling clinicians to easily see the status of any intervention. Because Actions in openEHR encapsulate a 'state' from the openEHR state machine, the latest Action in any thread gives the current state of the Instruction. |
Standardised support for care pathway data management and application development. |
|
Terminology |
SNOMED-CT Integration guide |
++ |
Guidelines for integration with SNOMED-CT. The context model for SNOMED-CT is now rich and enthusiasts are promoting post-coordination of increasing complexity. The openEHR architecture provides a mechanism for coordinating different elements of complex data in a way that is sustainable and can be queried using standard tools. Simplification of implementation of SNOMED is possible through use of constraint statements as part of templates and archetypes that provide the set of terms (in a browsable form) that are appropriate at any given data point. |
Simplification of deployment of SNOMED. |
|
|
|
|
|
|
|
|
|
|
IMPLEMENTABLE TECHNOLOGY SPECIFICATIONS |
|
|
XML Schemas |
XSDs for openEHR release 1.0.3 |
++ |
Ongoing maintenance of CRs and implementation triggered changes and backward compatibility |
Release of 1.0.3 XSD |
|
|
XSD for new AOM / TOM |
++ |
Design of efficient and simplified XSD for AOM 2.1 |
|
|
XSLT rendering scripts |
Generic XSLT for openEHR data in XML |
+ |
Further work and 'beautification' of the generic XSLT transformation for clinicians reading openEHR data where there is no specific transform available. |
|
|
|
|
|
TOOLING |
|
|
Parsers |
Eiffel ADL Parser |
++++ |
Implementation of ADL 1.5 / templates in the Eiffel reference parser |
|
|
|
Java ADL and XML Parser |
+++ |
Implementation of ADL 1.5 in the Java parser |
|
|
|
C# Parser |
++ |
Adaption of the Eiffel ADL parser to run in .Net Implementation of the C# XML Parser for AOM 2.1 |
|
|
Knowledge authoring tools |
CKM support |
++ |
CKM support for the Java 1.5 ADL and XML parser and other transformation tools |
|
|
|
Archetype Editor |
+++ |
Upgrading the archetype editor to provide demographic and ADL 1.5 archetypes |
|
|
|
Template Editor |
++++ |
Build an open source template editor based on ADL/AOM 1.5 specifications. |
|
|
Downstream generation tools |
Template to Form |
++ |
Automatic generation of a data entry form from an operational template that can be deployed in applications and over the web. |
Direct support for visual application building in various technologies |
|
|
Template to XSD |
+++ |
Automatic generation of XSD from an operational template. |
Message definitions from knowledge artefacts |
|
|
Template to programming object |
+++ |
Automatic generation of programming language API from operational template |
Direct support for application building where custom UI is being used. |
|
UML |
Determine UML tooling for openEHR specifications |
+++ |
Some work has been done on this by Erik Sundvall (Linköping University, Sweden). |
New tool agreed to provide openEHR UML models |
|
|
Republish the openEHR UML models |
++ |
The Release 1.0.1 model is published online , but contains some errors, and also the source model is no longer maintained due to out of date tooling. A new expression of the current release reference model is required in a new tool, to enable ongoing maintenance. Also, the XMI file is badly out of date (XMI 1.1). The online HTML model site, which has been indispensable to developers for some years, would be updated and corrected. Re-use of the model computationally (e.g. as XMI or EMF files) would be possible. |
New UML models and HTML view for release 1.0.2 and AOM changes. |
|
Publishing |
Convert Specification to DITA format |
+ |
All specification documents are currently in Adobe FrameMaker internal format. The tool remains the recognised industry leader in technical publishing but is expensive and takes some time to learn. Framemaker 8 now supports DITA XML and with some work and review the documents could be made available in DITA XML format which would make then editable in a number of tools including a simple XML editor. |
Specifications held in DITA XML format |
|
|
|
|
|
|
|
|
|
|
DE JURE & DE FACTO STANDARD SUPPORT |
|
|
Standards |
openEHR -> ISO 13606 mapping |
+++ |
Finish the formal mapping, enabling data conversion software to be written |
|
|
|
Template -> HL7 CDA |
++ |
Increase the repository of XLST transformations for openEHR data to be transformed to and from HL7 CDA format. |
Increase number of published CDAs supported by openEHR |
|
|
Template -> ASTM CCR |
++ |
Increase the repository of XLST transformations for openEHR data to be transformed to and from ASTM CCR format. |
Provide CCR support in openEHR out of the box. |
|
|
HL7/OMG CTS2 support |
|
|
|
|
|
HL7/OMG EIS/RLUS support |
|
|
|
|
|
IHE PDQ, PIX support |
|
|
|
|
|
Microsoft CHF support |
|
|
|
|
|
|
|
|
|
|
|
|
|
KNOWLEDGE ENGINEERING |
|
|
Archetypes |
Upgrade to ADL 1.5 (differential archetypes) |
|
Archetypes in CKM need to be upgraded to ADL/AOM 1.5. This primarily affects the 10% or so that are specialised. |
Archetype maintainability and correctness will be improved. |
|
|
|
|
|
|
|
|
|
|
INFRASTRUCTURE |
|
|
Servers |
openEHR.org server |
|
|
|
|
|
CKM server |
|
|
|
|
|
build server |
|
|
|
|
|
system administration |
|
|
|
|