SEKE 2012 Proceedings - Knowledge Systems Institute

B. STEP 2: Model Level
This section introduces a model as a simple case study that
specifies the structure, com monalities, and variabilities of tw o
types of XM L messages respectively conformed HL 7 CDA 2
and openEHR standards 3 . An XML product line then w ill be
generated after the model is interpreted by the inte rpreter
described in Section 3.C-F. Fi gure 2 shows the summary of an
EMR product line modeled by FODA. For space consideration,
please find model examples at [8].
TABLE I. VECTORS TO STORE XML ELEMENET PROPERTIES.
Index Element Parent Index Parent Index
0 ObservationEvent -1 -1
1 code 0 5
2 Value 0 0
3 Name - 0
4 Mappings - 3
5 Target - 4
6 terminology - 5
7 match - 4
8 value - 3
Figure 2. Summary of an HL7-CDA-and-openEHR product line.
C. STEP 3:Interpreter Level -- Create Data Structures
In order to keep track where each XM L element is located
and its relationships to other elements before and after applying
feature relationships, tw o 4 two-dimensional vectors are
introduced (For space consideration, Table 1 consists of two
vectors which are distinguished by Columns 3 and 4). Column
2 stores a list of Element objects, each of which contains its
feature relationship to its parent elem ent, (i.e. m andatory,
optional, one-of, or more-of). Columns 3 and 4 respectively
store the parent indices of ele ments of two standards. Note that
Column 3 has three integers. It is because Indices 3 to 8 should
only be included in the openEHR message by using Add. When
the six newly introduced feature relationships are identified in
the model, Column 4 should be updated accordingly. For
example, Add, Fold, Make_Tag, and Add_Remove with
Add_Attr value may increase an element’s parent level if the
structure is changed; and Inverse and Remove may decrease an
element’s parent index. The table not only assists in updating
elements’ properties and relationships but also finding where to
insert ending tags. Due to space consideration, please refer to
[8] for the algorithm of creating data structures.
D. STEP 4: Interpreter Level -- Create FDL Files
Feature Description Language (FDL) [6] is a domainspecific
language that describes feature models. Hence, STEP 4
is to generate FDL programs based on the results of STEP 3
(i.e., properties stored in Table 1) so that the FDL Rule Engine
[6] in STEP 5 can execute the FDL programs. The interpreter
starts from the root element and then retrieves those elements
2 Health Level 7. http://www.hl7.org.
3 openEHR. http://www.openehr.org.
4 There could be more than two vectors. The reason “two” are created is
because the product line conforms to two standards.
whose parent index indicates that they are the child elem ents of
the current element being processed. Then depending on the
parent-child feature relationshi p stored in the elements, the
interpreter generates the textual representation for the elem ent.
The processes are repeated for each element.
E. STEP 5: Interpreter Level -- Execute FDL Rule Engine
The FDL Rule Engine [6] is used to normalize and generate
all the possible com binations of XML elements from a given
FDL program. The output is a comma-separated list of XM L
elements for each unique possible combination.
F. STEP 6: Interpreter Level -- Generate an XML Product Line
The outputs from the FDL Rule Engine show all the
possible combinations of XM L elements based on feature
relationships, both newly introduced and FODA’ s. However,
there is no w ay to relate X ML elements to their parent
elements from the outputs, as they do not show parent
elements at all. Such outputs do not offer any idea of the levels
at which each element is present either. All this information is
necessary in order to generate a valid XM L product line that
conforms to HL7 CDA and openEHR. In order to solve this
challenge, the vectors generated in STEP 3 are used. The
interpreter parses one com bination of elements at a time. It
traverses a vector and checks if an element is present in the
current string of the combination of elements being
considered. If yes, it adds all the child elem ents and attributes
for the current element. Thus, the parent elements are added to
the message. The interpreter then checks if any attribute is
supposed to be converted into an element by checking
Make_Tag property value and converts it into the element
form and appends it to the m essage. It also checks if any
attribute is to be added or removed using Add_Remove. The
process is recursively repeated for every entry in the vector
and an X ML message is then generated. T he interpreter
continues to generate the rest of the XM L messages based on
the number of combinations from the FDL Rule Engine.
G. A Case Study
This section introduces a m ore complicated case study that
consists of all the feature relati onships mentioned in the paper.
539