Clinical Statement Flavour DSLImplementations
Purpose
This document specifies the implementations for the clinical statement flavour domain specific language. All of the solutions will be for use in the scenario of a user building a specification from predefined clinical statement flavours.
Audience
This document is intended to inform the tooling decisions that HL7 and project committees would encounter when realizing a domain specific language in tooling.
TextualImplementations
Toolbox containing basic predefined clinical statement flavours (ObsCoded, ObsCodedPQ etc.)
Drag and Drop into main editor pane
Apply constraints using free text editing or dialog box
Graphical Implementations
Modelling Approach
The graphical tool will be functionally similar to many other graphical editing environments and should offer a tool palette, a main editor pane and a properties window for objects on diagrams.
The red area shows the tool palette, this would contain the primary objects for the clinical statement flavour domain specific language. The objects would be added to the diagram using drag and drop. The blue area is the main editing window.
The properties window will be used for constraining parameters and could be launched as a dialog box or alternatively be available as a sidebar in the main window. A list of previously defined clinical statement flavours should be available in a drop down box to allow further constraint of existing types.
Treeview Based Approach
The treeview based approach would use a combination of treeview, project browser and properties controls. The project browser would be used to give an overview of all the clinical statement flavour packages that form a specification and would be used to select a package to be edited using the treeview control. The treeview control would be used to determine how clinical statement flavours are refined. Individual clinical statement flavours would be edited using a properties window as used in the modelling approach.
MindMap Based Approach
The mindmap based approach would use the widely used mindmap notation. This approach would have the big advantage of a simplified notation for the clinical statement flavours that would be understood by both technical and clinical audiences. The diagrams could be created either directly using a tool like XMind or generated from the domain specific language definition. This would open up the possibility of using the diagrams as a review tool for definitions created using a different, more technical` approach.
Form Based Approach
The form based approach would allow users to refine clinical statement flavours via a form interface. A dropdown box would be populated with existing clinical statements flavours that are visible from within the current package. The selected flavour will be refined to create a new flavour. All of the editing of classes and their attributes will be carried out using a form with a GridView similar to the example below:
Anticipated Changes
Mock UI editor view.
Archetype editor