Total Pageviews

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.



Saturday 1 December 2012

Way of Working

In the previous blog I have written about my plan of action. Now, I’ve also visualized my way of working.
  1. In blue: the main steps I have defined and will make.
  2. In green: the input for the main steps. The input also needs to be obtained, but the necessary steps for this are not the main steps.
  3. In purple: the goal of this literature study and the eventual output. A recommendation for the Annotation Method which seems to be best for annotating process oriented care descriptions, like clinical guidelines (specifically in the light of the current research discussed in the FHIES article).
  4. In red: already obtained output from the first step: the selected Annotation Methods.
Fig. 1 Way of Working


Adjustment based on comments

Since I misunderstood the functionality of SHARE, I had to adjust the Way of Working. Figure 2 represents the updated version and shows the 2 types of annotation tools that will be investigated.
Fig. 2 Adjusted Way of Working

Thursday 15 November 2012

Back on Track

Based on my previous blog and the feedback I've gotten, I can now set the direction in which I will be working. As stated before, I will investigate collaborative annotation methods which can be used as a step for the generation of an App as CDSS. However, I will no longer only focus on web-based annotation systems. After reading the FHIES article* by Van Gorp et al (2012) and a Skype meeting with my supervisor Pieter Van Gorp, it is now clear that it is better to also investigate other programs/platforms. Therefore, I will investigate 4 different methods which could be used to annotate different process-oriented models in healthcare (e.g. clinical guidelines).

The methods I will investigate are:
1)     GEM Cutter II
2)     EuGENia
3)     SHARE
4)     Web Annotation Tools

These methods are chosen based on the research of the above mentioned FHIES article and experience of Pieter Van Gorp. Since I am not familiar with these methods, I will have to investigate each one thoroughly. I will start by looking up general information and reading articles concerning these methods. After this I will also try to work with them to get a better feeling on how they actually work.

Eventually, I will try to argue which method is most applicable for the collaborative annotation of process-oriented models in healthcare. This decision will be made on yet to determine criteria.

*Full article name: 'MDE support for process-oriented health information systems: from theory to practice' by Van Gorp et al (2012)

Adjustment based on comment

It seems I have misunderstood the functionality of SHARE. I, therefore, want to restate the methods I will investigate. They will be of two different types:
1) SHARE-executed Desktop Tools:
     - GEM Cutter II
     - EuGENia
     - ...
2) Web Annotation Tools:
     - Diigo
     - Zotero
     - ...

Thursday 8 November 2012

Restart in Vienna

After lots of new impressions and nice experiences in and around Vienna, it is now definitely time to continue with my literature study. Because new beginnings are often hard, I have reread and inspected my previous work to get inspiration.

Inspiration came and I decided to take a different step than I described in my third blog. This because I first want to retrieve more information about Web annotation and its history. I think this will give me a good basis to think about the criteria for a suitable web-based annotation program.

To find articles I've used Google Scholar and I searched with the terms: Web Annotation, Web Annotation System and Annotation. The relevance of articles was determined by looking at the title, inspecting the abstract, and the number of citations. Furthermore, I took the year of publication into consideration. From this search I got 23 articles which seem to contain useful information. Furthermore, I found an interesting article while inspecting the wiki about Annotation on Wikipedia.
This makes a total of 24 articles about Web Annotation and Web Annotation Systems, which I want to inspect. However, just starting to read did not feel like a good idea. I wanted to make annotations and cross references along the way, work on multiple devices, and work in an orderly way. So, I need an Annotation program, but which one to choose?

Which Annotation programs are available? Which features do they have? Are they available for free? So my next search started. First, I started by looking for PDF annotators, because all articles are in PDF-format any way. This made me stumble on a really nice forum (astrobetter.com) which discussed PDF annotators for (astrophysical) articles. About 7 programs where discussed and one of them was Mendeley which has the feature of collaboration. This made me realize, I really want that feature in my program, since it is useful now and it will be useful later on as well when I need to decide on a program.
In the end I had a list of 11 annotators from which 5 have the possibility of collaboration:

  •           Bluebeam Revu
  •           Mendeley
  •           Zotero
  •           Qiqqa
  •           EndNote
These programs I will investigate further: what are their features? What are the similarities? The differences? Then I’ll decide upon which one or two I will start to use and then the article reading starts…

Tuesday 7 August 2012

The next step: setting up criteria

To compare different web-based annotation software one needs criteria on which to assess the programs. These criteria can be set up in a top-down or a bottom-up fashion. The first method is used to investigate what functionality of a program is needed, while the second method is used to investigate what functionality a program already has. For this study I will combine both methods. Therefore, criteria will be obtained top-down by talking with an IS expert (dr. Van Gorp), an healthcare expert (dr. Kubben), and probably setting up a group meeting with or questionnaire for other experts. Next to this the bottom-up criteria will be obtained by looking and testing different web-based annotation programs.

The obtained criteria need to be grouped. Possible main categories are annotation options, output, and compatibility. The first category could include the option to categorise notes; the second category the content and format of the output; while the third category will include the compatibility of software on different devices like an Ipad.

Sunday 17 June 2012

Annotation

What is annotation exactly? What types of annotation are there? And which type would fit my project? My first step is to just ‘google’ annotation and find an understandable and good working definition for myself. Annotation is a critical or explanatory (body of) note(s) added to any form of text. An example that immediately comes into my mind is a highlighted sentence in a summary or book. Wolfe and Neuwirth (2004) have identified four functions of annotation in their article. Annotation can be used to:
1)     Facilitate reading and later writing
2)     Eavesdrop on insights of other readers
3)     Provide feedback for the writer
4)     Call attention to topics and important passages
The functionalities of annotation are very useful in the process from scientific article to CDSS app. The goal of the annotation step in this process is to filter out the most important information of the article and then turn this into a flowchart. To be able to do this, medical specialists will have to work together to annotate scientific articles. By collaborative annotating they can call attention to important topics and passages and facilitate reading for specialists who will read the article after them. They can help each other and make use of each other’s insights.
Annotating used to be done on paper, but now it is also possible to this on a web resource: web-based annotating. A user needs web annotation system to add, modify, and remove information from a web resource. This system makes it possible to annotate in a separate layer so the original source is not modified. Web-annotating has several applications. For instance, web-annotating can be used to rate a web resource or to improve the content of a source. A third option is to use web-annotating for collaborative annotating since it is easy to share (annotated) documents with the annotation software. Therefore, web-based annotating can be a helpful tool to support the collaborative annotating process by the medical specialists.
As a next step, I am going to investigate and compare different web-based annotation system. This comparison will be, among others, based on the user-friendliness and different features, like the option to highlight text, make different types of notes, and the type of documents that can be annotated.

Monday 14 May 2012

Kick - Off


My name is Anouk Suntjens and I am studying Operations Management and Logistics (OML) at the Eindhoven University of Technology (TU/e). Currently, I am preparing for my Master Thesis and part of this is setting up a blog. On this blog I will provide updates concerning my project and I hope to receive input, so everyone who has input/feedback/comments is welcome to give it/them. J

My Master Thesis concerns Model-Driven Engineering (MDE) for Clinical Decision Support Systems (CDSS); more specifically, I am going to look at (collaborative) annotating methods. CDSS already indicates the context for this research is the healthcare domain and MDE techniques can be used to generate applications (apps) from, for example, existing guideline(s). Annotating is the first step in this process: the important concepts need to be identified. Secondly, flow charts can be made and eventually apps. I am going to look at the annotating step and investigate the different methods and possible ways of collaborative annotating.

My project will be supervised by my mentor dr. Pieter Van Gorp, an assistant professor in the IS lab at the TU/e, who is part of the BPM and healthcare research clusters. Furthermore, I will collaborate with Dr. Pieter Kubben, a neurosurgeon at the Maastricht University hospital, who has already written several apps for neurosurgery.