Total Pageviews

Monday 4 February 2013

Step III: Criteria for Comparison of the Annotation Methods

After an introduction of the different Annotation Methods, it is now time to collect criteria for the comparison of the Methods. Which Annotation Program will be the best one to annotate medical documents? The criteria are based on my meetings with Dr. Pieter Van Gorp, the FHIES article (Van Gorp et al. 2012), and the literature review by (Novak et al. 2012).

The criteria are classified in three categories:
  1. Annotation options 
  2. Output 
  3. Compatibility 

Annotations options:

This category covers the options needed for the annotation process. Two main criteria are discovered: 
a. Collaborative annotating: medical experts have to be able to collaborate in the annotating process. The medical documents have to be annotated by multiple experts to ensure correct annotations. Furthermore, discussions about or explanations of annotations need to be possible. Therefore, group annotations and notes are selected as needed annotation options. 

b. Functional annotations: this indicates the option to give functional meaning to certain annotations. For example, if a symptom is annotated, this annotation should be given the function ‘symptom’. This will make the annotation process structured and it will make the creation of models possible after the annotation. Since the creation of models is a known step after the annotation, functional annotations is selected as a needed annotation option.


Output:

It is wanted to be able to create models after the annotation process; therefore, the output of the annotation process is of interest. The export of the annotated parts is wanted. The content and type of output file are of interest. The output needs to be computer-interpretable to automatically create models after the annotation. Furthermore, the content must include the annotations and their function; and a link with the original document must be maintained. 


Compatibility:


To create ease of use, the annotation program/method, must be compatible with:

c. Multiple operating systems 
d. Multiple devices, like PCs or tablets 
e. Different types of documents: To be able to annotate all different types of medical documents and to create a generally applicable program. 

Furthermore, synchronization needs to be in place to prevent double and/or conflicting annotations. 

Figure 1: Spiderweb of Criteria

In Fig. 1: Spiderweb of Criteria, the different categories and criteria are shown. My next step will be to discuss these criteria once more with Dr. Van Gorp. After approval, I will compare the different annotation programs/methods with these criteria.


Fig. 1: Spiderweb of Criteria

Sources: 
  • Van Gorp, P. et al., 2012. MDE Support for Process-Oriented Health Information Systems: from Theory to Practice.
  • Novak, E., Razzouk, R. & Johnson, T.E., 2012. The Educational Use of Social Annotation Tools in Higher Education: A Literature Review. Internet and Higher Education, 15(1), pp.39–49.

Friday 1 February 2013

Step II E: Selection of Web Annotation Tools

Based on the findings of Novak et al. (2012) and a quick search on Google (Web Annotation Tool), the following web annotation tools are investigated: 
  1. HyLighter
  2. VPen 
  3. SpreadCrumbs 
  4. EDUCOSM 
  5. Diigo 
  6. Zotero.


HyLighter

HyLighter is a browser-based collaboration platform. Novak et al. (2012) describe it as an online SA system that allows users to highlight and annotate in an electronic text and share it with others. One has to buy a license for HyLighter to be able to use it.


VPen

Virtual Pen (VPen) is a Web-based online annotation system developed by (Hwang et al. 2007). This tool was built to investigate the influence of annotation and the sharing of annotations on learning performance.


SpreadCrumbs

Novak et al. (2012) state that SpreadCrumbs has been developed to explore how students annotate electronic resources. Kawase et al. (2009) designed SpreadCrumbs as “an annotation system that provides an interface for adding post-it notes and crumbs (i.e., personal reminders) to any point within a Web page”. Furthermore, bookmarks and the sharing of annotations are possible.


EDUCOSM

Nokelainen et al. (2003) have developed EDUCOSM. This tool focuses on the possibilities of collaboration and the open-ended nature of the Web. Sharing and annotation of arbitrary Web-pages are possible. Furthermore, the EDUCOSM system consists of a set of tools including search, filters, and others for asynchronous collaborative knowledge construction (Novak et al. 2012).


Diigo

Diigo is a Web 2.0 SA tool. On its website developers describe Diigo as “a cloud-based personal information management system”. It runs on different operating systems and web browsers. Annotations, bookmarks, and highlighting are possible and saved in an online personal library. Collaboration and sharing are optional. Furthermore, this annotation tool is freely available.


Zotero

“Zotero is a free, easy-to-use tool to help you collect, organize, cite, and share your research sources”, according to its developers. Zotero is also a Web 2.0 SA tool. Zotero can be used to organize and tag documents, however, it is not possible to annotate or highlight documents.



Sources

  • Hwang, W.Y., Wang, C.Y. & Sharples, M., 2007. A study of multimedia annotation of Web-based materials. Computers \& Education, 48(4), pp.680–699.
  • Kawase, R., Herder, E. & Nejdl, W., 2009. A comparison of paper-based and online annotations in the workplace. Learning in the Synergy of Multiple Disciplines, pp.240–253.
  • Nokelainen, P. et al., 2003. Evaluating the role of a shared document-based annotation tool in learner-centered collaborative learning. Advanced Learning Technologies, 2003. Proceedings. The 3rd IEEE International Conference on, pp.200–203.
  • Novak, E., Razzouk, R. & Johnson, T.E., 2012. The Educational Use of Social Annotation Tools in Higher Education: A Literature Review. Internet and Higher Education, 15(1), pp.39–49. 
  • HyLighter Website
  • Diigo Website
  • Zotero website

Step II D: Web Annotation Tools

The second category of tools are Web Annotation Tools. In this blog I will present general information about Web Annotation Tools. 

Web Annotation Tools (WATs) allow annotations on HTML documents, i.e. on a web resource, like a web page. Rau et al. (2004) describe the major functionalities of WATs as “highlighting texts, inserting and editing annotations, organizing and presenting annotations hierarchically, and sharing annotations”. The annotations occur in a separate annotation layer, so the original source is not modified.

WATs can be used for individual or shared annotating. According to Glover et al. (2007), this sharing of notes (with people who have the same annotation system) is one of the two major advantages of inserting annotations into web resources. The second major advantage is the possibility to access the annotations from any web enabled computer.

If WATs are used for sharing than they are a type of Social Annotation (SA) tool. Social Annotation Technology is “an online social bookmarking tool that allows annotations on an electronic resource and supports easy online information sharing” (Novak et al. 2012). SA technology also provides a social platform for interactions and discussions.

Collaborative annotating is one of the key conditions for the annotating tool that is needed in this project, since medical experts must be able to annotate the medical documents in collaboration. Therefore, the larger category, Social Annotation Tools, is closer investigated. Novak et al. (2012) have found that the number of social annotation technologies grows due to “the need for using such tools in various settings and the benefits this technology offers”. One of these benefits is the created sense of community among the users in a given system and the resulting involvement in the community (Bateman et al. 2006). Novak et al. (2012) conclude that educationally used SA tools are found beneficial for collaborative learning. These benefits are positive for this project, however, they also state that it is best to use small teams (2-3 people) for collaborative SA activities. This is a recommendation to keep in mind when implementing the annotating tool.

Sources:
  • Bateman, S., Farran, R., Brusilovsky, P. & McCalla, G., 2006, November 8-10. OATS. The open annotation and tagging system, Paper presented at the Third Annual Inter- national Scientific Conference of the Learning Object Repository Research Network, Montreal. 
  • Glover, I., Xu, Z. & Hardaker, G., 2007. Online annotation-Research and practices. Computers & Education, 49(4), pp.1308–1320.
  • Novak, E., Razzouk, R. & Johnson, T.E., 2012. The Educational Use of Social Annotation Tools in Higher Education: A Literature Review. Internet and Higher Education, 15(1), pp.39–49.
  • Patrick Rau, P.L., Chen, S.H. & Chin, Y.T., 2004. Developing web annotation tools for learners and instructors. Interacting with Computers, 16(2), pp.163–181.

Tuesday 15 January 2013

STEP II C: SHARE

GEM Cutter II and EuGENia are both desktop-oriented applications. To make these annotation tools web-accessible, SHARE is selected as a possible execution platform. But how does SHARE work and what is SHARE actually an abbreviation of?

SHARE stands for Sharing Hosted Autonomous Research Environments and it is “a web portal that enables academics to create, share, and access remote virtual machines that can be cited from research papers (Van Gorp & Mazanek, 2011).” Van Gorp and Mazanek have develop this execution platform “to provide fellow scientists and researchers a convenient way to reproduce computational results of research papers”.

Authors can use SHARE to create a virtual machine that contains all software, operating systems, and data they have used to execute their research. Readers can then login with SHARE and use this virtual machine (via a Remote Desktop Protocol server) to reproduce the results of the paper. SHARE helps users and prevents them from having to install additional programs.

People who want to use SHARE will have to sign up and create an account. SHARE-users can upload files to remote virtual machines; however, they cannot download artifacts to their own computers. This is useful with respect to copyrights and licensing. Another advantage of SHARE is that multiple users can use the same virtual machine at the same time. In this way multiple researchers can inspect the same research at the same time.

The characteristics of SHARE definitely fit well to make GEM Cutter II and EuGENia web-accessible. Annotators will not have the burden to install specific programs, they will just have to sign up with SHARE.

Sources:

Wednesday 12 December 2012

Step II B: EuGENia

In this blog I will investigate a second annotation tool, named EuGENia. This is step II B, so I will find general information about EuGENia to get a good first impression.

EuGENia is “a tool that automatically generates the .gmfgraph, .gmftool and .gmfmap models needed to implement a GMF editor from a single annotated Ecore metamodel” (EuGENia Website). A nice description from the official EuGENia website, but it contains a lot of words/definitions I don’t immediately understand. So the first step is to understand this definition.


1) What is a GMF? And a GMF editor? 
GMF is the abbreviation for the Graphical Modeling Framework. GMF graphically represents EMF (Eclipse Modeling Framework) and EMF is used to build tools and other applications based on a structured data model (e.g. metamodel). Together with tools and runtime support to produce a set of Java classes for the model, EMF provides a basic editor for a Domain Specific Language (DSL). GMF has the aim to implement a graphical editor for such a DSL. 


This indicates that a GMF editor is a graphical editing surface for any domain model in EMF, e.g. a UML modelling tool. 
2) What is Ecore and an Ecore metamodel? 
Ecore is an EMF’s metamodel; it is the general model from which any EMF model can be described. An Ecore metamodel is an Eclipse Modeling Framework (EMF) model used to implement other EMF models. Ecore and Ecore metamodel are used inter-exchangeable. Its representation is in XML Metadata Interchange (XMI ), which is an Object Management Group (OMG) standard for exchanging metadata information via Extensible Markup Language (XML).

Ok, let’s see if the definition is now easier to understand:

EuGENia can be seen as the higher level tool that hides the complexity of the Graphical Modeling Framework. GMF implements a graphical editing surface based on an annotated Ecore metamodel, which is a general Eclipse Modeling Framework model from which any EMF model can be described. EMF is used to build tools and other applications based on a structured data model. 


It becomes better, but I think I need to understand EuGENia really well and I must be able to describe it. So, let’s try to visually show the relation between EMF, GMF and EuGENia. I use the slides presented at the EuGENia website for this.





Seeing it graphically always helps me to better understand something. So let’s try again to describe EuGENia. 

EuGENia is a tool to design a graphical editor. This editor is made in several steps.

  1. First one needs to have a metamodel of the model category; this indicates one needs to have a general model of the models one wants to make (DSL). 
  2. The second step is to add GMF-based annotations to this metamodel. This is necessary because EuGENia is the higher level tool of the GMF editor and in the fourth step, the functionality of GMF is applied. There are different annotations which can be added to, for instance, the classes. These are added in the metamodel with @-signs.
  3. From the metamodel and the annotations, three different GMF-models are derived: 
    1. The tooling model
    2. The graph model
    3. The mapping model 
  4. As a last step, the GMF-functionality is applied on these models. This results in a graphical editor.
I think I now understand and the previous description works for me. Next step, how can this annotation tool be seen in the big picture, i.e. how can EuGENia be used to annotate care documents, like clinical guidelines?

A graphical editor, which makes it possible to annotate and store care documents, could perhaps be written with EuGENia. For this one needs a metamodel. Van Gorp et al (2012) already mention a possible extension of the EuGENia metamodel. In step 3 B, I will explore this option deeper.


Background information

To understand the bigger picture of the relations with and ownership of EuGENia, I developed the following hierarchy:


In dark Blue one can see the section, family, framework, project, and community EuGENia belongs to. Starting at the bottom:

  • EuGENia is one of the tools of Epsilon, “a family of languages and tools for code generation, model-to-model transformation, model validation, comparison, migration and refactoring that work out-of-the-box with EMF and other types of models” (Epsilon Website). 
  • Epsilon is part of the Eclipse Model Framework Technology, which also contains the Graphical Modeling Project (GMP). As part of GMP, the Graphical Modeling Framework (GMF) has been designed.
  • The Eclipse Model Framework Technology is part of the Eclipse Modeling Project, which in turn is a project of Eclipse. Eclipse is “a community for individuals and organizations who wish to collaborate on commercially-friendly open source software. Its projects are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle” (Eclipse Website).

Wednesday 5 December 2012

Step II A: GEM Cutter II

GEM Cutter II (general information)

The GEM Cutter II is an XML document editor and it is part of the Guideline Elements Model (GEM) developed by the Yale Center for Medical Informatics at Yale University School of Medicine. The GEM Cutter II is able to transform textual clinical guideline information into GEM II formatted XML. 

To be able to explain the GEM Cutter II better, I will first elaborate on the Guideline Elements Model (GEM).

GEM is a model developed by Yale to assist the translation of clinical guidelines into a lay out computers can process. If we want technology to assist e.g. medical practitioners with clinical guidelines, then a translation is needed. This means clinical guidelines written in natural language are to be translated into a format that computers can process.

GEM is a model that “can store and organise the heterogeneous information contained in clinical guidelines”. This indicates that the model can be used to get a good overview of the knowledge provided by stakeholders in different articles. Each stakeholder will put emphasis on his/her orientation and therefore a good overview is useful (Shiffman et al (2000)). E.g. implementers of guidelines will put emphasis on the practical implications of a clinical guideline and less on the scientific concept/validity; while the developers of guidelines will provide the theoretical validity of the guideline and less conceptual recommendations. GEM can organise and represent this heterogeneous information.

In 2000, the first article about GEM was published. Now, in 2012, the second version, GEM II, is in use. The improved GEM II has, for example, more branches to contain the elements. These branches are, for instance, “purpose”, “intended audience” and “method of development”. Each branch contains several elements, which can be filled with information from the original document.

(GEM Hierarchy - Source: GEM website by Yale Center for Medical Informatics
This is where the GEM Cutter II comes in as a tool. The XML document editor can be used to mark up the wanted parts of the clinical guideline and categorize them under the right element. In this way the textual clinical guidelines are transformed into GEM II formatted XML. The user does not even need programming knowledge for this transformation. There is a user guide available, so I will investigate how easy it really is...

Sources:
 

Sunday 2 December 2012

Step I: Selection of Annotation Methods to be investigated


In the blog “Way of Working”, I have set out the steps I’m going to take. As can be seen in Fig. 1 Way of Working, the first step is “Selection of Annotation Methods to be investigated”. As input for this step I take the FHIES Article by Van Gorp et al (2012) and the already mentioned Skype meeting I had with dr. Van Gorp. The output of this step are the different methods in the 2 categories: the desktop tools GEM Cutter II and EuGENia executed via SHARE, and the Web Annotation tools, like Diigo.

In this blog, I will summarize the FHIES article and my Skype meeting.


Summary of FHIES article

The actual title of the article is ‘MDE support for process-oriented health information systems: from theory to practice’. Van Gorp, Vanderfeesten, Dalinghuis, Mengerink, van der Sanden and Kubben have written this article in 2012 and presented it at the Foundations of Health Information Engineering and Systems (FHIES) International Symposium of 2012. “The paper leverages model-driven engineering techniques to improve (the use of) health information systems that are process-oriented” (Van Gorp et al (2012)).

In the paper Van Gorp et al discuss Model Driven Engineering (MDE) technology and its potential to improve workflow management and decision support in the healthcare sector. MDE is defined as “a software engineering method to generate or configure powerful tools with the use of explicit modelling language and model transformation definitions” (Van Gorp et al (2012)).

The focus of the paper is specifically on tool-supported derivation of the formal models from unstructured text. This means Van Gorp et al have evaluated the tool support for systematically deriving clinical guideline models from medical literature. MDE tools are chosen because:

  1. “They are known to excel in the linkage of models at various levels of abstraction. 
  2. They are known to support the co-evolution of conceptual models with derived software systems” (Van Gorp et al (2012)).
Related tool support is performed by the Yale Center for Medical Informatics. Therefore Van Gorp et al have investigated the GEM Cutter IIThis method has not been used  in this project because it does not fit the aims set for the annotation tool:

  • An annotation-based model extraction infrastructure based on Eclipse ECore and EMF (industry-standards for metamodeling in MDE) 
  • Support of visual models (e.g. flowcharts) 
  • Adaptability of metamodels (useful for clinical guidelines, but also for CPRs, CPAs, etc).
The last point already hints to it, in the paper clinical guidelines are taken as an example to show the relevance of annotation-based model extraction. However, the last point also mentions the adaptability of metamodels. This means that another aim is to make the tool support also useful for other process-oriented medical texts. Because there are lots of different types of texts, Van Gorp et al have made a classification for all process-oriented models in the Health Informatics literature. They have identified two dimensions: 
  1. patient scope: 1 individual patient, multiple patients of 1 care group, and any type of patient; 
  2. provider scope: 1 organization or multiple organizations working as 1 (virtual) organization/network, and multiple organizations.
Next to this they have identified 6 main ways used in literature to describe medical texts in these 6 categories: 
(1) Clinical guidelines (CGs), (2) Clinical Protocols (CPs), (3) Care Pathways (CPAs), 
(4) Individual Care Pathways (ICPs), (5) Assigned Pathways (APs), and (6) Reference Pathways (RPAs). 

These dimensions and their categories are visualized in Fig. 1 ‘2D Classification of Process Oriented Care Descriptions’.



Next, Van Gorp et al state that they will investigate “metamodel-based language support for each class of process descriptions” (in the future) and they discuss their first practical results: “the application of model-driven engineering techniques for managing better the relation between clinical guidelines, clinical protocols and their derived applications” (Van Gorp et al (2012)). They state for this relation not only computerized transformations are needed, but also consensus building by various medical specialists. This is because flowcharts are often used for documenting guidelines, but their modelling basis is not that well-founded, so by strengthening this, new opportunities arise.


MDE Support for Clinical Guidelines

The 2D classification is extended with time as a next step to show the need for formally interconnecting the models from the 2D space (Fig. 2). In today’s HIS architectures the theoretical instantiation, specialization, and update-of links are, in general, largely implicit. Explicit links could help to better analyse the relation between the different documents in practice: i.e. “how evidence-based descriptions of optimal medical care (CGs) relate to nurse management systems (CPRs) and patient logistic systems (CPAs and ICPs) and planning systems (APs)”. Therefore, metamodels that enable the formal representation of all artefacts in this space are needed. After this, the links between the models and their individual elements can be provided conveniently.

From this Van Gorp et al state the following hypothesis: “MDE techniques can primarily contribute to the better management of related artefacts over time.”



Fundamental steps that are needed to enable MDE support for any cell of fig.2: 
  1. Analyses of which modelling languages are relevant to the problem at hand. This means a metamodel (i.e. abstract syntax, that defines the language definition) has to be made
  2. Put MDE techniques to action.
The case for Clinical Guidelines:
1. CG tend to be documented in plain text, but in many cases also formalized with flowchart 
    notation. These, however, tend to be published only as images and many times only a 
    subset of the flowchart notation was used. This means a need to enrich the model elements
    with additional metadata was discovered. 
    --> Eclipse Epsilon suite has been used to define the abstract and concrete syntax of 
           the newly developed flowchart-based language for CG modelling. 
            - The metamodel structure/abstract syntax is defined by classes and associations.
                § There are 2 types of nodes: the classes action and decision
                § There is an attribute added that enables to associate one or more medical 
                   papers to a flowchart. (useful for traceability)) 
            - The concrete syntax is defined by means of annotations.
2. A) Generation of a special purpose flowchart editor based on metamodel definition
          --> chosen format is Eclipse Modeling Framework (EMF) 
    B) Development of a prototypical code generator for translating the flowchart 
         models into source code files for mobile Android devices

The special purpose, metamodel based editor (described above) provides a promising basis for storing CG in a shared repository. “However, one crucial step has been overlooked so far: the primary publication artefact of a clinical guideline is still plain text.” Unfortunately, no generic MDE tool infrastructure to ease the development of the text annotation component has been found. Therefore, Van Gorp et al implemented an ad-hoc Java Swing application to annotate. However, “generic support for building interactive text to model derivation tools is needed.” 

Van Gorp et al emphasize that grammar-based automatic text-to-model transformation tools are largely irrelevant in this model mining context since the input texts do not adhere to grammatical rules. This means that grammar-based tools use a certain fixed structure of a sentence to form a model from the text. Since medical text are not always build up in the same way, nor is the structure of every sentence always the same, this means that grammar-based tools are not useful in this case.

Model-Driven, Evidence-based, Development of CDS Apps

As mentioned before, Van Gorp et al (2012) have developed a prototypical tool-chain to show how MDE techniques can help to transform plain text clinical guidelines (CGs) into flowcharts and a Clinical Decision Support App (CDS), which can be used by medical practitioners.

Steps of the chain:

  1. Medical specialists annotate scientific CGs. Context: in their continuous learning process or during a regularly planned literature review cycle within a hospital. Annotations are stored in a computer-interpretable form. 
  2. Guideline annotations are transformed into a flowchart skeleton model. 
  3. The flowchart is manually refined. 
  4. The flowchart is transformed into a CDS app. 
Fig. 5 illustrates the steps.

The currently used annotation tool annotates the following: 

  • Title: Green 
  • Observations: Yellow 
  • Actions/Treatments: Red 
  • Explanatory elements: Blue 
By clicking compile the representation is translated into the flowchart EMF format of the flowchart editor. 

Final flowchart:

  • Edges in the figure are still created manually 
  • Explanations are not shown but these could be added 
App

  • Initially, it represents a searchable list of guidelines (title of CG) 
  • After selecting a CG, the App shows the question at the root node of the decision tree. The user can answer with yes (“on”) or no (“off”) 
  • The next questions follow until there is evidence for a certain action. 
  • The medical specialist can get more background information by pressing “Info”.

Observations

Van Gorp et al conclude that “the implementation of the prototype has confirmed the confidence in the potential of MDE techniques for the development of better process-oriented health information systems.” Furthermore, the following observations were made: 

  1. “MDE technology was particularly strong for generating a specialized editor: the Eugenia component of the Eclipse Epsilon suite has supported best so far. 
  2. The use of advanced features of MDE code generators such as Acceleo would have slowed the project down rather than facilitated it. 
  3. The MDE community has overlooked the support for extracting models from annotated texts.”

Annotation Tool Recommendations

With regard to annotation tools, Van Gorp et al make the remark that an extension of the Epsilon platform seems like a good idea to them. This would mean that the text annotation tool is generated from a metamodel. Now Eugenia transforms a metamodel specification into a visual model editor. Van Gorp et al propose a new functionality for the Epsilon platform: Generated Annotation Editor. This editor should contain “a palette with buttons for creating specific annotations in the text” which is shown next to the palette. By mapping the buttons directly to element attributes of the corresponding model it becomes possible to annotate the metamodel definitions in such a way that the Eugenia can automatically generate the button’s behaviour. 

Van Gorp at al leave it open if the annotation editor is a separate tool or if it is integrated with the model editor. Either way, they propose to store the complete texts and the begin and end indices of annotations inside the EMF based output model.


Conclusions


  • Based on a thorough literature study, this paper presented a clarification and novel classification of the existing process-like descriptions in the healthcare domain in order to derive support for these processes through model-driven engineering techniques. 
  • 2 dimensions to distinguish types of descriptions: # organizations, # patients. 
  • Tool chain developed for CG to illustrate how MDE techniques can enable the stepwise development of mobile clinical decision support apps. 
  • This paper motivates a previously undocumented need for tools to extract models interactively from annotated texts. à Extension of Epsilon (state-of-the-art MDE toolsuite) so that an annotation-based extraction tool can be used for formalisms other than flowcharts.


Skype Meeting with Dr. Van Gorp

After reading the article I had a Skype meeting with Dr. Van Gorp. He answered my questions concerning the above summarized article and we talked about the direction of my literature study. 

Concerning the direction of my literature study (as mentioned in the blog ‘Back on Track’) I will investigate which annotation method is most useful in light of the research described in the FHIES article. These are: GEM Cutter II, EuGENia, SHARE (a cloud environment), and Web Annotation Tools.

Topics discussed:


  • GEM Cutter II: this annotation method needs lots of specific parameters. The environment is too complex and detailed for the project (described in FHIES). GEM Cutter II is specifically designed for CGs, so not for other process-oriented care documents. This is mentioned in the article with the phrase: based on one metamodel. A method which is accessible/adjustable to any modelling language is wanted. (Important to understand: investigate (e.g. article about study with GEM and CGs).) 
  • ECore and EMF: these are technologies which are used to work with metamodels. It is not necessarily to understand these completely, because EuGENia hides lots of their functionality. 
  • EuGENia: this method works on ECore and EMF. There has just been the release of a new version. As mentioned in the article, it might be a good idea to enrich the metamodel with annotation options linked to visual elements. This indicates an editor will have to be designed for this. It is unknown if an annotation tool can be added in the EuGENia program next to the model editor tool. (Important to understand: investigate thoroughly (e.g. tutorial, minor project).) 
  • SHARE: this is a cloud environment. It can be found on the platform of Van Gorp. (Important to investigate thoroughly (e.g. articles, online environment).) 
  • Web Annotation programs: these programs work completely online. This is thus different from desk top programs, like Qiqqa (mentioned in another blog). (Important to investigate and get full understanding of term (e.g. websites).) 

  • Metamodel: model of a model or a modelling language. This means the structure, semantics (what the models and programs written in the language mean and how they behave) and constraints for a family of models are described (Mellor et al (2004)). The MDA describes a metamodel as abstract syntax and a data model to store, manipulate and interchange models. 
  • Overview of current annotation tools: it is important to make an overview of the currently existing annotation tools with their properties. Input and Output needed and provided are important factors to keep track of. 
  • Also focus on different process-oriented medical texts: in the end is important that the annotation tool can be used for different types of medical texts, i.e. not only applicable for Clinical Guidelines. 
  • Annotation tool criteria: the criteria on which to compare the different annotation tools will be mainly based on recommendations/wishes of dr. Kubben. It is an option to ask his colleagues, but this is to be decided upon later.

Concluding

In the literature study I will investigate 4 different annotation methods: GEM Cutter II, EuGENia, SHARE, and Web Annotation tools. These methods will be compared and eventually the method which is most useful as an annotation tool in the tool chain described in the article (from medical text to CDS app) will be recommended.