Model based Validation of XML Requirements, Applied on Healthcare

IT Standards

Abderrazek Boufahja

and Eric Poiseau

Gazelle Team, Kereval / IHE-Europe, Rennes, France

Gazelle Team, Inria Rennes / IHE-Europe, Rennes, France

Keywords:

Model-based, Validation, Requirements, XML, Healthcare Standards, Schematron, Interoperability, Quality.

Abstract:

Nonconformity of healthcare implementations to the medical standards has become a real source of troubles

and loss of interoperability between systems. Healthcare documents frequently contain inconsistent require-

ments related to the standards they must conform to. Few standards and methodologies exist to deal with

complex requirements, and often they are only dedicated to some speciﬁc kinds of healthcare standards, like

CDA, HL7 and DICOM. The complexity of standards and their constant evolution have made difﬁcult the

implementation of robust check methods and tools for healthcare documents. In this paper, we propose a

novel model-based validation methodology, which allows enumerating and validating requirements related to

healthcare documents that have XML based structure. Model-based methodology deﬁned and speciﬁed in

this paper allows checking any kind of requirements even for healthcare documents with complex standards’

cascading. Experimentations of model based checking demonstrate that this method was highly effective in

detecting inconsistencies, and orienting implementers of healthcare technologies.

1 INTRODUCTION

Numerous regional and national healthcare initia-

tives are requiring eHealth applications to be tested

for conformance to proﬁled standards. Meaning-

ful Use (Melissa Markey, 2012) in the USA, Elga

(Georg Duftschmid, 2009) in Austria or ASIP (ASIP,

2012a) in France illustrate the desire of healthcare or-

ganizations to build an infrastructure to share PHR.

Most of those initiatives are proﬁling the HL7 CDA

(HL7, 2005a) standards and/or the IHE XDS (IHE,

2012a) proﬁles speciﬁcations. CDA speciﬁes how to

structure and code health records while XDS provides

the sharing mechanism of these records.

Testing the conformance of healthcare solutions

becomes an important issue in order to achieve the in-

teroperability of the different components contribut-

ing to the sharing of such documents. Since both XDS

messages and CDA documents have an XML struc-

ture, we have developed a methodology that allows

the conformance checking of XML documents in the

context of hybrid healthcare standards. This method-

ology is based on UML modeling and MDA approach

to describe the speciﬁcations. The main idea of this

methodology is to inject constraints into UML mod-

els instead of executing xpath rules into XML docu-

ments. The result of this methodology is a report of

validation generated automatically from the models

describing the healthcare standards.

Following a review of existing solutions for vali-

dating XML documents in the ﬁeld of healthcare we

will present our methodology and its evaluation based

on its use on real life project like epSOS (Thorp,

2010) (epSOS, 2013).

2 STATE OF THE ART

Numerous tools provide validation of healthcare stan-

dards based XML technology. However, most of

them are based on Schematron standard and MDHT

project’s methodology. This section provides an anal-

ysis of these methods.

2.1 Schematron

2.1.1 Presentation

Schematron is an ISO/IEC standard that offers the

possibility to create complex rules, like conditional

rules, iterations over nodes, nodes content compari-

son, etc. This set of schematron rules can be used to

295

Boufahja A. and Poiseau E..

Model based Validation of XML Requirements, Applied on Healthcare IT Standards.

DOI: 10.5220/0004776902950302

In Proceedings of the International Conference on Health Informatics (HEALTHINF-2014), pages 295-302

ISBN: 978-989-758-010-9

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

check the conformance of an XML document. Many

groups are using schematron rules for the validation

of XML documents (Lee, 2000). There are open

source tools that allow validating an XML document

regarding a schematron, and they are widely used

and maintained by a large community, offering some

trust in the performance and the quality of the stan-

dard. A schematron document is basically composed

of multiple xpath assertions, which represent the rules

that the tested XML document shall verify (Clark and

DeRose, 1999).

2.1.2 Strengths and Weaknesses

Schematrons are efﬁcient when used for few rules,

and they are simple to use as they are an inter-

preted language. However, schematrons have multi-

ple weaknesses. First the processing of the schema-

trons is too long. When hundreds of rules are to be

veriﬁed, the validation takes too much time. The sec-

ond problem is the use of xpath as language of con-

straint. Xpath is known to be a difﬁcult language and

hard to debug (Clark and DeRose, 1999). Also, the

code deﬁned by hundreds of xpath rules is not easy to

read and to understand. As a consequence, it is not

easy to maintain a set of schematron rules. Another

weakness of schematrons, there is no real coupling

between requirements and rules. Moreover, there is

no automatic generation of documentation. We can-

not know for an existing schematron if a requirement

is checked or not. Furthermore, there is no unit test-

ing generation for the written rules. Finally, there is

no support for changeable value sets. In healthcare

standards, the list of technical keywords grows fre-

quently. There are no techniques on the schematrons

that allows using a dynamic validation regarding to a

dynamic list of a standard value sets.

2.2 MDHT Project

2.2.1 Presentation

MDHT is an open source tool developed and main-

tained by Open Health Tools (Sondra Renly, 2012), a

not-for-proﬁt Trade Association, incorporated in the

United State of America. MDHT is dedicated to doc-

ument and to validate medical IT standards that are

based on HL7 CDA standard (HL7, 2005a). The aim

of the project is to offer a tool that allows the descrip-

tion of the requirements related to healthcare speci-

ﬁcations based on HL7 CDA standard, in a simple

UML model. As output, the tool provides a docu-

mentation of the requirements, the java source code

for the manipulation (read and write) of CDA docu-

ments, and a validator of CDA documents related to

the standard described in the UML model. MDHT

provides an eclipse plugin for the edition of the under-

lying UML model. A large community uses MDHT

as a reference of development and for requirements

validation and documentation (example: CCD, IHE,

HITSP, etc).

2.2.2 Strengths and Weaknesses

MDHT is an excellent tool for CDA document val-

idation with a large user base. However the tool is

designed for CDA and can not be easily extended to

the validation of XML documents which are not CDA

documents, like XDS messages or XDW documents

(IHE, 2012b), as the proﬁle of UML stereotypes that

describe the UML models is based on the structure of

CDA documents.

3 MODEL BASED VALIDATION

OF HEALTHCARE

DOCUMENTS

3.1 Objectives

Our goal is to create a method that allows describing

formally all requirements under an XML healthcare

standard. This method should be generic and support

inheritance between standards. The performance of

this method shall be comparable to the performance

of schematrons, and even better. This method shall

provide a documentation and a coverage of the imple-

mented requirements. The maintainability of the tools

and models shall be better than schematrons maintain-

ability. The method described here provide also gen-

erated unit testing for each implemented requirement,

which is a huge advantage comparing to schematrons.

The outcome of the proposed methodology is to pro-

vide a UML model and a set of methods used to con-

vert it into documentation, validators and test proce-

dures (Hans-Erik Erikson, 2004).

Standards Inheritance: We can point as exam-

ple two standards that share the same basic parent

standards, and extend them with more rules and re-

quirements. These standards are the Swiss CDA Lab-

oratory documents (eHealth Suisse, 2013), and the

French CDA Laboratory documents (ASIP, 2012b).

These two kinds of documents are based on the stan-

dards below, described on the ﬁgure 1. The two stan-

dards have a common base, and differ only on the top

of the pyramid of standards. The method described

here takes care of this kind of inheritance, and allows

having shared models for shared standards.

HEALTHINF2014-InternationalConferenceonHealthInformatics

296

Figure 1: Inheritance between healthcare standards.

3.2 Principle

Figure 2: Principle of model based validation of XML

healthcare documents.

The principle of the method that we propose for the

validation of XML documents based on UML de-

scription, is the following (ﬁgure 2):

1 - From medical standards like HL7, DICOM

(Hongli Lin, 2010) and IHE standards, we extract all

requirements, and we insert them into a speciﬁc UML

model, which has a speciﬁc structure, that we will

describe later. The UML model contains constraints

written in OCL (Object Constraint Language) (OMG,

2012). The purpose of this language is to describe

the relationship between elements of the UML model,

which can not be simply described by diagrammatic

notation. Each OCL constraint represents a require-

ment on a medical standard. OCL is a powerful lan-

guage that permits many variants of constraints, like

loops, search constraints, conditional constraints, etc.

By our experience on more than 50 validators of IHE

documents, OCL can generate the description of any

kind of rules related to the model. The created UML

model contains also the structure of the XML doc-

ument. This structure allows linking the OCL con-

straint to its corresponding XML element.

2 - The OCL constraints are then processed to

a programming language code like JAVA. In the in-

dustry, there are many processors of OCL. The most

popular one is DresdenOCL, which is a library de-

veloped and maintained by students and scientists of

the Software Technology Group at Dresden Univer-

sity of Technology (Birgit Demuth, 2009) (Birgit De-

muth and Zschale, 2004).

3 - The UML models and the processed OCL con-

straints are then used by a UML model to text gen-

erator (M2T), to generate a speciﬁc validator based

on the UML contents (OMG, 2008). There are many

projects that present themselves as a UML model to

text tool, the most popular one is Acceleo (OMG,

2008). Acceleo is not a classic generator of code from

UML models, like EMF generator. To generate code

you have to provide some M2T templates, which de-

scribe the generated text from the model. The gener-

ated text can be of any kind: html, java, or C++ for

example. The idea was to generate java code that al-

lows transforming the XML document to be validated

from XML to JAVA instances, and then to validate

these java instances by using the code generated by

the OCL processor. The M2T method allows also to

generate a documentation of the UML model, and unit

tests for constraints written on OCL. Each module is

described by its M2T templates.

3.3 Healthcare Requirements

Management

Requirements on healthcare documents are generally

written on human language, not a formal one. A

major problem of the maintainability of schematrons

was the fact that once the schematron written, we

do not know which requirements are described on

it, and which ones are not. We have no information

about the coverage of rules written on schematrons,

according to requirements from healthcare speci-

ﬁcations. Many tools offer the possibility to list

requirements, like TestLink for example. The one

that we chose was an OASIS standard: taml (OASIS,

2011). This standard is a common structure for

deﬁning requirements. We used this standard and

restricted its structure to better conform to the context

of requirements on healthcare documents. This

standard allows specifying the list of predicates, and

for each predicate you can specify a list of tags which

describe the predicate. We restricted the tags to:

’section’ and ’page’, which describe the section on

the document and the page that refer to the require-

ment. Each predicate is deﬁned by a unique identiﬁer

ModelbasedValidationofXMLRequirements,AppliedonHealthcareITStandards

297

(/taml:testAssertion/@id), and each list of require-

ments is deﬁned by a unique identiﬁer: /testAssertion-

Set/common/normativeSource/target/@idscheme.

We restricted the OASIS taml standard by imposing

that the common element of the taml:testAssertionSet

shall be present, and this common element shall

contain information about the healthcare document

that we are processing, like the document name,

version, source name, and a URI to the original

document. These properties are included in the

element taml:common/taml:refSourceItem. We

forced the taml descriptor to have a unique identiﬁer

by adding the element taml:common:/taml:target.

This is an example of taml assertion token from the

taml document of CDA PADV speciﬁcation:

<predicate>The Pharmaceutical Advice section

SHALL contain code.</predicate>

</testAssertion>

Each requirement is identiﬁed by a unique couple (tar-

get@idscheme , testAssertion@id). So we deﬁned

a stereotype applied on UML constraint elements,

which describes the relationship between constraints

and requirements (ﬁgure 3). It contains two attributes:

IDs and targetIDScheme, where IDs represents the

list of ID on the taml document, and targetIDScheme

is the identiﬁer of the taml document.

Figure 3: Relationship between rules and requirements.

This correlation between constraints and require-

ments allows calculating the coverage of the valida-

tor according to the list of requirements, and then to

identify requirements that are not implemented in the

UML models.

3.4 UML Models’ Speciﬁcation

3.4.1 Constraints’ Speciﬁcation

Each requirement extracted from the speciﬁcations of

the XML document is translated into a UML con-

straint that contains an OpaqueExpression element

with the attributes:

• language: ’OCL’

• body: the OCL constraint

The OCL constraint shall always have the result

equals to true when applied to an UML instance spec-

iﬁcation. On healthcare standards, especially on HL7

ones, there are three kinds of rules: requirements,

warning, and notes, which are speciﬁed by the key-

word SHALL, SHOULD and MAY (Bradner, 1997).

We speciﬁed a stereotype applied on UML constraint

elements, which allows to specify if the constraint

is an error, a warning, or a note. This stereotype is

named ConstraintType (ﬁgure 4).

Figure 4: Stereotypes related to Constraint element.

We deﬁned also a stereotype to document a con-

straint when it is related to a valueSet: a dynamic

list of values, that can be provided by a CTS or a

SVS provider (IHE, 2010) (HL7, 2005b) (Heymans S,

2011). Each created constraint element shall be re-

lated to a UML class element.

3.4.2 Classes’ Speciﬁcation

There are two kinds of UML classes in this methodol-

ogy: classes used to describe the content of the XML

document, and classes used to apply a list of rules on

a kind of XML element.

1- Classes used to Describe the Content of the

XML Document: These classes, called in our spec-

iﬁcation StructureClass (SC), contain attributes with

the same structure described in the schema of the

XML document. The proﬁle used to describe the

relation between classes and the schema elements is

’Ecore’ proﬁle (Dave Steinberg, 2008). From an XSD

we can generate the UML model containing the de-

scription of the content of the XML document. The

principal stereotypes used from this proﬁle to describe

the XML structure are: EPackage, Eclass, EEnum,

EAttribute, and EReference. The generation of code

binded to XML is based on these stereotypes. On this

kind of classes, basic constraints can be included. If

we are sure that a rule shall be applicable to any re-

striction of the standard, and it is not related to some

speciﬁc context, we can add it directly on the class of

description of the element.

2- Classes used to Apply Rules on a kind of

XML Element: When we are on a special speciﬁ-

cation of a standard, or on an afﬁnity domain which

restrict the original standard, like for example epSOS

HEALTHINF2014-InternationalConferenceonHealthInformatics

298

CDA standard, we know that rules applied by these

standards are not absolute, and we can not attach

these rules directly to the class of description of the

element. We deﬁned the notion of ’package of con-

straints’. Each package of constraints contains a list

of classes of constraints, and each class of constraints

contains a list of constraints, has a generalization to

the parent UML StructureClass or to another class of

constraints, and has a stereotype that deﬁnes the kind

of the class of constraints.

We deﬁned three kinds of stereotypes that describe

the kind of a class of constraints (ﬁgure 5):

• TemplateSpec (TS): described by a (path, id). The

list of constraints on this class is applied only

when the value of the path on the XML instance

has the same value as the id

• ConstraintsSpec (CS): the list of constraints is ap-

plied automatically to any instance of the element

described by the parent class

• AdvancedTemplate (AT): deﬁned by an OCL rule.

The list of constraints on this kind of classes is

applied only when the speciﬁed rule is veriﬁed on

an instance of the parent class.

Figure 5: Stereotypes of classes of constraints.

The UML classes that are described by these

stereotypes are created manually in the UML model,

in order to provide restrictions on the StructureClass

(SC) classes, using UML constraints that describe re-

quirements of the speciﬁcations. However, the Struc-

tureClass(SC) classes are created automatically from

the XSD schema that describes the structure of the

XML documents to be validated (R. Bhuvaneswari,

2012). This schema is generally provided by the stan-

dard speciﬁcation.

The mixing of these kinds of classes of con-

straints can lead us to illogic situations, by gen-

eralization from one kind to another. So we de-

ﬁned some rules of inheritance between Template-

Spec (TS), ConstraintsSpec (CS), AdvancedTemplate

(AT) and StructureClass (SC).

When a class of constraints generalizes another

class of constraints, parent class rules are added to

the child class rules, and the two lists of rules are exe-

cuted only if we can execute the two lists in the same

time. If we allow a TemplateSpec to inherit from an-

other TemplateSpec, the rules of the child are exe-

cuted only if the element tested on the XML docu-

ment veriﬁes the two paths of the parent and the child

classes. If one of these paths is not veriﬁed, the rules

are not executed, and here we have a problem because

no error is reported to the designer of the XML doc-

ument, showing that the XML element is missing a

path, one or the other. For this reason, the table below

speciﬁes this kind of relationship between classes of

constraints (table 1).

Table 1: Inheritence between classes of constraints.

– TS CS AT SC

TS x x x v

CS v v v v

AT x x x v

SC x x x v

We described these relationships by a formal

grammar G = (N, σ, Y, P), where:

• Alphabet: σ = {T S, CS, AT, SC}

• Nonterminal symbols: N = {Y }

• Start symbol: Y

• production rules P:

Y → T S.SC

Y → AT.SC

Y → Y.SC

Y → CS.(SC|Y )

This can be described by the diagram below (ﬁg-

ure 6).

Figure 6: State diagram of classes of constraints’ relation-

ship.

The language deﬁned by G is:

L(G) = {CS

(T S|AT |CS)SC

;n, m ∈ N, n ≥ 0, m ≥ 1}

(1)

We also deﬁned a stereotype to document classes

of constraints, named DocumentationSpec. It allows

specifying information about the standard which is

the origin of constraints, and this provides a better

documentation of the class of constraints when gener-

ating the documentation of the model of constraints.

ModelbasedValidationofXMLRequirements,AppliedonHealthcareITStandards

299

3.5 M2T Generation’s Speciﬁcation

3.5.1 XML Binding

As explained on the principle of this method, as out-

put we need to generate a code that allows transform-

ing XML elements to object instances. In the imple-

mentation of this methodology, we chose JAXB as the

API to bind XML to objects (McLaughlin, 2002). Or-

acle provides a tool, named xjc (McLaughlin, 2001),

which allows to generate from an XML schema, java

classes containing a full description of the XSD ele-

ments, based on JAXB annotations. The same func-

tionality of generation of code containing a binding

with XSD elements is done by a M2T template. Cre-

ating our own generator of java code gives us the pos-

sibility to add further methods and attributes, that are

not generated by xjc. For example, we have intro-

duced the ability to validate xpath constraints as a

method of validation on the generated java code.

3.5.2 Validation Code

The second kind of output from UML models is the

classes of validation. This generated code is the com-

bination of the OCL code transformed and processed

by the OCL processor, and the generated code from

a M2T template that links rules between themselves.

The result of the execution of the generated code is

a list of veriﬁcations. This list contains errors, warn-

ings, notes and reports about processing of rules. For

each package of classes of constraints, we gener-

ate a class of validation. This technique allows the

reusability of the generated code, and simpliﬁes the

imbrication of standards. For example, in the labora-

tory domain described in ﬁgure 1, for each block in

the two pyramids, we deﬁne a package of constraints.

So for each of HL7 CDA, IHE PCC and XD-LAB,

we deﬁne a unique package of validation. Then we

deﬁne speciﬁc packages for CDA-FR, CDA-CH, and

LAB-FR, LAB-CH. The validator is the combination

of the common packages and the speciﬁc packages.

The M2T templates generate code based on the visitor

pattern: for each element on the object structure gen-

erated to describe the elements of the XML, we pass

an instance of the package of validation, to a method

generated from the template of generation of struc-

tured classes (ﬁgure 7).

This method veriﬁes the rules of the package on

the current instances, and calls the same method on

its attributes with the same package’s instance.

Figure 7: State principle of the visitor pattern applied on

XML elements validation.

3.5.3 Unit Testing Generation

The generation of unit tests is managed by a M2T

template to facilitate the process of unit testing. This

feature does not exist on the schematrons’ process.

The generated code provides for each constraint, two

tests: one OK and one KO. The principle of each test

is to validate a whole document, and to verify if the

result of the constraint is what it is supposed to be.

The speciﬁcation of the XML documents to be veri-

ﬁed can not be done automatically; it is the role of the

tester to provide them.

3.5.4 Templates Coverage

As we deﬁne a structure of templates and advanced

templates, the speciﬁed model of constraints provides

an overview of the complexity of the XML document.

This feature is very useful in CDA documents and in

XDS metadatas analysis, as the speciﬁcations of these

kinds of documents are based on templates structure.

For example, in CDA documents, sections and entries

have an attribute named templateId which is a unique

identiﬁer of the kind of the element, and it is refer-

enced by the TemplateSpec stereotype (HL7, 2005a).

3.5.5 Documentation Generation

The deﬁned stereotypes to document constraints and

classes of constraints are used for the generation of

the documentation. The generation is performed us-

ing a M2T template, with an html output. There are

two kinds of documentation that can be generated:

- the documentation of the structure of the XML

document: this documentation is a description of the

elements of the XML document. For each element we

can document the cardinality, the type, the name, and

the parent.

- the documentation of classes of constraints: this

documentation contains the relationship between con-

HEALTHINF2014-InternationalConferenceonHealthInformatics

300

straints and classes, documentation of the kind of con-

straints and the kind of classes of constraints, and ﬁ-

nally a documentation of the link between constraints

and taml assertions.

4 IMPLEMENTATION

4.1 Implementation Details

We have implemented and used this methodology for

the development of validators used by the Gazelle

Test Bed plateform (Eric Poiseau, 2010). The UML

editor used for the implementation is Topcased: it of-

fers a rich graphical editor, and provides an efﬁcient

search tool for an easy retrieval of constraint or the

attributes of a stereotype. The OCL processor used is

DresdenOCL and the M2T generator used is Acceleo,

as they are open source tools. The generated code for

the validation and testing is in JAVA and the gener-

ated documentation is in HTML. Acceleo templates

are packaged as an eclipse plugin, so a developer who

want to use the tool to create a validator for a speciﬁc

standard only needs to upload the plugin and to write

the UML models, and then to automatically generate

the java code of validation, the unit test code and the

documentation. So there are no further acceleo tem-

plates to write.

4.2 Developers Feedback

Developers who have used the model based tool to

create and update UML models were pleased to the

fact that OCL was easier to use than xpath on schema-

trons. The generated unit tests give a kind of conﬁ-

dence on the generated code, and the generated doc-

umentation is helpful for debugging when the valida-

tion fails. Also, UML models are easier to maintain

than schematrons. Developers at IHE-Europe have

tested this methodology and adopted it for numerous

IHE proﬁles. At the date of this publication, the num-

ber of model-based validators implemented by IHE

Europe is close to 80, and it is growing.

4.3 Users Feedback

The model based validation methodology was applied

to perform the validation of messages and documents

in various standards used in the ﬁeld of Healthcare.

Beside the use within the epSOS project for HL7

CDA and XDS metadatas validations, we have ap-

plied the methodology to other speciﬁcations in the

IHE domain. Today we applied it to many of the XML

based proﬁles, like DSUB, XDS, PDQV3, HPD, and

SVS. Users of these validators were satisﬁed by the

robustness of the validation. Moreover, sometimes

the implementation of model based validators allowed

us to detect inconsistencies between the speciﬁcations

and the referenced standards.

4.4 Performance Issues

The implementation of this methodology has proved

that the model-based validation is easier to main-

tain and to reuse than schematrons. Furthermore, the

model-based validators are faster than schematrons.

Figure 8: Comparison between execution time (ms) of the

validation using model based validation and schematrons.

The ﬁgure 8 reports the execution time for the

validation of a HL7 CDA documents on the epSOS

domain. Red curve represents the execution time of

schematrons (SCH) according to the number of rules

veriﬁed on a document, and the blue curve repre-

sents the execution time for the model-based valida-

tion (MBV) according to the number of rules veri-

ﬁed. 1300 samples CDA documents were processed

in order to plot these curves. The samples were pro-

vided from 20 national infrastructures of the Euro-

pean member states participating in the epSOS project

(McLaughlin, 2002). One can remark that for the

same number of rules processed the time of MBV

is smaller than for schematrons. In addition, as the

number of rules increases the execution time is ris-

ing faster for the schematron validation than for the

model based one.

5 CONCLUSIONS

In this paper, we designed a methodology of vali-

dation of XML documents on healthcare standards

based on model based architecture. This methodology

has allowed to remain with weaknesses of schema-

trons technology, especially problems of maintain-

ability, reusability, unit testing, documentation and re-

ModelbasedValidationofXMLRequirements,AppliedonHealthcareITStandards

301

quirements coverage. It has also simpliﬁed the vali-

dation of pyramidical standards.

The implementation of this methodology was

done using open source tools, especially Topcased as

editor, DresdenOCL as OCL processor, and Acceleo

as M2T generator. The generated output code was

on Java technology. The result of this implementa-

tion has covered the needs of developers and users of

the generated validators. The use of this methodology

to create validators for multiple kinds of healthcare

standards in many domains like epSOS and IHE has

proved the efﬁciency of this method: any kind of con-

straint can be expressed. And also, an important fea-

ture was, the model based validators are quicker than

schematrons.

Several improvements could be injected into this

methodology and its implementation, like a self edi-

tor of the UML model, to simplify the creation and

the management of classes and constraints. Also, the

concept of stereotypes to describe classes and con-

straints can evolve to a meta-model that describes this

set of stereotypes, and a use of GMF can improve the

usability and minimize the risk of inconsistencies of

UML models. Moreover, the model based validation

of XML based healthcare standards could be adapted

to other domains that use the XML technology.

REFERENCES

ASIP (April 25, 2012a). Cadre d’interoprabilit

e des

SIS, Document chapeau. Agence des syst

emes

d’information partag

es de sant

ASIP (October 15, 2012b). Volet Compte Rendu d

Examens

de Biologie M

edicale. Asip Sant

e, v1.3.0.0 edition.

Birgit Demuth, C. W. (2009). Model and object veriﬁcation

by using dresden ocl. In Proceedings of the Russian-

German Workshop Innovation Information Technolo-

gies: Theory and Practice. Ufa State Aviation Techni-

cal University, Ufa, Bashkortostan, Russia.

Birgit Demuth, S. L. and Zschale, S. (September 15 - 17,

2004). Structure of the dresden ocl toolkit. In The

2nd International Fujaba Days : MDA with UML and

Rule-based Object Manipulation. Technical Univer-

sity of Darmstadt, Germany.

Bradner, S. (1997). RFC 2119 : Keywords for use in RFCs

to Indicate Requirement Levels. W3C recommenda-

tion, Harvard University, Boston, Massachusetts.

Clark, J. and DeRose, S. (November, 1999). XML path lan-

guage (XPath) version 1.0. W3C recommendation.

Dave Steinberg, Frank Budinsky, M. P. E. M. (Decem-

ber 16, 2008). EMF: Eclipse Modeling Framework.

Addison-Wesley Professional.

eHealth Suisse (May 21, 2013). Format d

echange Rap-

ports de laboratoire soumis

a d

eclaration en Suisse.

eHealth Suisse.

epSOS (January 03, 2013). epSOS Architecture and Design

Interoperability Speciﬁcation. Smart Open Services

for European Patients.

Eric Poiseau, Karima Bourquard, M. O. M. Z. (2010). Test-

ing Tools Strategy. Healthcare Interoperability Testing

and Conformance Harmonisation (HITCH).

Georg Duftschmid, Wolf gang Dorda, W. G. (2009). The

elga initiative: A plan for implementing nationwide

electronic health records system in austria. In Medical

University of Vienna.

Hans-Erik Erikson, Magnus Penker, B. L. D. F. (2004).

UML2 Toolkit. Wiley Publishing, Inc.

Heymans S, McKennirey M, P. J. (2011). Semantic valida-

tion of the use of snomed ct in hl7 clinical documents.

In Journal of Biomedical Semantics.

HL7 (June, 2005b). HL7 Version 3 Standard: Common Ter-

minology Services. Health Level Seven, release 2 edi-

tion.

HL7 (May, 2005a). HL7 Clinical Document Architecture,

Release 2.0 (CDA), Normative Edition. Health Level

Seven.

Hongli Lin, Zhencheng Chen, W. W. (2010). Xml schemas

representation of dicom data model. In Bioinformatics

and Biomedical Engineering (iCBBE).

IHE (August 10, 2010). IT Infrastructure Technical Frame-

work Supplement, Sharing Value Sets. Integrating the

Healthcare Enterprise.

IHE (August 31, 2012a). IT Infrastructure Technical

Framework. Integrating the Healthcare Enterprise.

IHE (August 31, 2012b). IT Infrastructure Technical

Framework Supplement, Cross-Enterprise Document

Workﬂow (XDW). Integrating the Healthcare Enter-

prise.

Lee, D. . C. (September, 2000). Comparative analysis of six

xml schema languages. In ACM SIGMOD.

McLaughlin, B. (2002). Java And Xml Data Binding.

O’Reilly.

McLaughlin, B. (August, 2001). Java and XML. O’Reilly,

second edition.

Melissa Markey, M. M. (2012). Practice manager panel:

Putting ehrs to meaningful use in the medical ofﬁce,

perspectives from practice managers. HIMSS.

OASIS (November 2011). Test Assertions Markup Lan-

guage (TAML). Advancing Open Standards For the

Information Society (OASIS), v1.0 edition.

OMG (January, 2008). MOF Model to Text Transformation

Language. Object Management Group, v1.0 edition.

OMG (January, 2012). OMG Object Constraint Language

speciﬁcation (OCL). Object Management Group,

v2.3.1 edition.

R. Bhuvaneswari, K. K. (February 2012). Software support

for xml schema design patterns and pattern matching

of xml schemas. In International Journal of Scientiﬁc

and Research Publications, Volume 2, Issue 2.

Sondra Renly, Rita Altamore, L. N. (November, 2012). A

new model for collaboration: Building cda documents

in mdht. In AMIA Annual Symposium Proceeding.

Thorp, J. (September, 2010). epsos project, an overview of

european interoperability initiatives. In AHIMA.

HEALTHINF2014-InternationalConferenceonHealthInformatics

302