Äîêóìåíò âçÿò èç êýøà ïîèñêîâîé ìàøèíû. Àäðåñ îðèãèíàëüíîãî äîêóìåíòà : http://www.cplire.ru/rus/telemed/CEN251/Terms.doc Äàòà èçìåíåíèÿ: Tue Dec 10 19:02:31 2002 Äàòà èíäåêñèðîâàíèÿ: Tue Oct 2 07:30:26 2012 Êîäèðîâêà: Ïîèñêîâûå ñëîâà: ìåçéòï÷áîéå

[pic] |EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITè EUROPèEN DE NORMALISATION
EUROPäISCHES KOMITEE FýR NORMUNG |CEN/TC 251/N02-002
2002-02-14
| |


|CEN/TC 251 |
|Health Informatics |
|Secretariat: SIS-HSS |






|TITLE/ |Final draft of Technical Report: Health informatics -|
|SUBJECT: |Vocabulary - Maintenance procedure for a web-based |
| |terms and concepts database |
| |CEN/TC 251/WG II |
|SOURCE: | |
| | |
|ACTION |For approval at the CEN/TC 251 meeting 2002-03-26 |
|REQUIRED: | |







| | FINAL DRAFT |
|TECHNICAL REPORT |prCEN/TR xxxxxx |
|RAPPORT TECHNIQUE | |
|FACHBERICHT | |
| |January 2002 |
| | |
| | |
|English version |
| |Health informatics - Vocabulary - Maintenance procedure for a| |
| |web-based terms and concepts database | |
| | | |
| |
| |
| |
|This final draft of a Technical Report is submitted for approval to CEN/TC |
|251. |
| |
| |
|CEN members are the national standards bodies of Austria, Belgium, Czech |
|Republic, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, |
|Italy, Luxembourg, Malta, Netherlands, Norway, Portugal, Spain, Sweden, |
|Switzerland and United Kingdom. |
| |
| |
| |
| |













| |EUROPEAN COMMITTEE FOR | |
| |STANDARDIZATION | |
| |COMITè EUROPèEN DE | |
| |NORMALISATION | |
| |EUROPäISCHES KOMITEE FýR | |
| |NORMUNG | |
|Management Centre: rue de Stassart, 36 B-1050 Brussels |
|¿ 2002 |All rights of exploitation in any form |Ref. No. prTR xxxxx:2002 E|
|CEN |and by any means reserved worldwide for| |
| |CEN national Members. | |
Foreword

This informative Technical Report has been drafted by CEN/TC 251, the
secretariat of which is held by SIS - Swedish Standards Institute.

This report is replacing ENV 12017:1997, Medical Informatics - Medical
Informatics Vocabulary (MIVOC).


Introduction

The need for a coherent and precise terminology in health informatics is
obvious. The overall problem of supplying concept systems and reference
terminologies with international scope for all of healthcare information is
gigantic but is approached by different organisations and strategies where
formal standardization aims for a facilitating role.

This work addresses the much more limited problem of the terminology of
informatics and in particular the terminology used in health informatics
standards. Vocabulary harmonisation across standards in the field is an
important quality requirement and with the growing complexity of health
informatics, easy to use tools are needed to manage this. We have to accept
that in some aspects terminology and definitions of the associated concepts
are developing over time. It is therefore important for the vocabulary to
be continuously updated with new terms and unambiguous definitions with
references to the normative documents where they are approved.

The proposed database described in this report is intended to be able to
serve, firstly the international work in the English language but can also
serve as an important facilitator of national implementations of CEN
standards. Finally, it should be pointed out that an updated and
comprehensive reference terminology of health informatics, especially if
available in multicultural/multilingual format, will be an important
facilitator for the development of the European market of IT products and
solutions for health that reach far beyond the standardisation process.

In ENV 12017 a procedure was described in which a published standard would
regularly be issued with the most recent terminology. Given the fast
development and requirement for easy access, CEN/TC 251 decided in March
2000 to instead target a freely available database with web access, which
would present the terms and definitions of the CEN/TC 251 standards. The
intended capacity to present concept models graphically when available,
together with the traditional verbal definitions, makes it extra valuable.



Scope

This work Technical Report describes the general requirements on a terms
and concepts database. This Technical Report also proposes a maintenance
procedure for CEN/TC 251, the content, structure and user interface to a
web-based terms- and concepts database that will compile the defined
concepts with their preferred terms and definitions from the standards
developed by CEN/TC 251. These are terms from the health informatics field
and not all terms and concepts used in healthcare.

It also describes an example of an implementation and ends with a proposal
for CEN/TC 251 for the establishment and maintenance of such a terms and
concepts database.


Abbreviations


T&C Terms and Concepts

Strategy for defining a Terms and Concepts database

Definitions of concepts reached by graphic modelling are in many ways
preferable to text-only definitions. By concept modelling, the definition
becomes much more strict, and possible overlappings and circular
definitions become overt. In many CEN/TC 251 standards, graphic models are
used to define concepts but there are also many terms in the existing
standards that are only presented with textual definitions. CEN/TC 251
should seek to develop concept models in the future work.

The database should therefore have the capacity to present the definitions
both verbally (which is more easy to read) and graphically (which is more
exact).

This Report starts with an introduction to graphic modelling where general
requirements on different types of models are described.

However, terms as identifiers of concepts are of course also essential. By
mapping preferred terms and synonyms to concepts defined by their links to
surrounding concepts, it is possible to create a dictionary. The synonyms
can also be national terms. In the multilingual Europe this would be of
special interest. The database can also hold synonyms intended for
technical use in ICT-systems such as XML-tags in addition to terms intended
for human reading.

If the field of usage of a term mapped to a certain concept is specified,
it is possible to use the same term in some other specified context mapped
to another concept. If implemented in the database, handling of homonyms
and versions is made possible. By indicating the status and source for
terms and concepts, inclusion of normative information from other
standardisation bodies than CEN is made possible.

The intended content of terms and concepts will be collected from existing
normative documents with reference to it's source and domain.

A meta-model for the relations in between terms and concepts and the usage
and source of terms is presented in Annex B.

Functional demands on a web-based, graphical terms- and concepts database
has been described by STG (Swedish General Standards Group) within SIS -
Swedish Standards Institute in relation to its work on geographical
information systems. This work is presented in Annex A.

An investigation and enquiry was made during this project on available
tools that met these requirements. The result of this is presented below
under Available tools.

Finally, essential aspects of the maintenance procedure required are
presented. Please note that the important issue of resources for such work
is outside the scope of this Report.



General requirements on a language for notation of concept models


Different models have different purposes

To be able to understand and interpret a model, it is necessary to know for
what purpose the model is made and what it describes. It is important to
distinguish between concept models and data models, since they describe two
separate phenomena.

Concept models

Concept models describe the language (terms and concepts) that is used when
people communicate within and about a certain activity. The purpose with a
concept model is to explain the meaning of a concept that is to be
denominated by a certain term.

Data models

Data models are different collections of models used in connection to
production of data systems. They depict the data to be handled in the data
system. The purpose of a data model is to show how the data to be handled
is structured and processed.
Concept modelling is a prerequisite for making a correct data model, since
the data model is described by terms; and if they are not unambiguously
defined by concept modelling, we don't know exactly what we are describing.

The relations in between concept-, process- and data models are illustrated
in Figure 1.

Languages for modelling

The structure of natural languages people are using in between themselves
differ a lot from the structure of data to be handled automatically.
Modelling languages intended for concept modelling offer simple
descriptions of the linguistic constructions people use. But since they can
not simply be implemented in an information system, data modelling
languages are not structured for simple depiction of these linguistic
constructions.

Since the models are created by and intended for persons with quite
different competence profiles, separate demands are put on a language
suitable for concept modelling compared to a language intended for data
modelling.

A language for concept modelling should be as simple as possible to learn
for a person not used to read models, since concept modelling is mostly
involving skilled professionals from the floor with no previous experience
in modelling. It should preferably contain as few components as possible,
and a restricted amount of syntax.
A language for data modelling is on the contrary intended to be used and
read by system professionals, needing a rich and more complicated syntax.
UML - Unified Modelling Language is the de facto standard for this purpose
used in CEN/TC 251 standards.





Figure 1. (For explanatory comments, see annex C).


Semantic meta model

There is a need for a semantic meta model that defines the relations in
between terms and concepts, the usage of terms, and how concepts relate to
each other, thus defining their meaning.

Predefined types of relations combined with a set of cardinalities enables
dynamic link creation, and solves the previous problems with vast number of
links in other term systems.

In real life the same term often applies to different concepts (homonyms)
depending on the context. It is important that the model offers a method to
circumscribe the usage of terms in a relevant manner. In healthcare this
could be the specialty and/or professional group using the term. Or it
could be a local application, or a period of time.

In Annex B a semantic meta model is presented developed by Sven-Bertil
Wallin during the CEN/TC 251 WG II work on a standard for Semantic Links
(see working documents WGII/N01-09 and WGII/N01-08).




Data model

The data model for the T&C database should be based on the semantic meta
model, to be able to handle both terms of different kinds and use, and the
concepts and their relations. The data model also must handle a verbal
description of each concept (possibly in versions), together with a verbal
structural definition; which will be the written normative definition as
depicted in a graph - one for each concept.


Graphic interface

It is suggested that each concept is presented in one image, containing a
textual part to the left and a graphic part to the right. On top of the
textual column the recommended term for the concept will be the headline.
Accepted synonyms can be listed below the recommended term. Below that, the
description of the concept (i.e. the traditional verbal definition) will be
presented, with the structural normative definition underneath. At the
bottom clarifying comments and references to close concepts will be added
when needed.

The graphic part will be interactive with the textual part and with other
concept graphs. This means that when a concept is clicked upon in a graph,
it will centre itself in the picture and the relations to surrounding
concepts will be drawn. Simultaneously the corresponding text is presented
in the left column as described above.

Thus it will be possible to move around in the graphic part, step by step.
Together with this, overview graphs of variable magnification will ease the
navigation, when chosen.

In Annex D an example is given to illustrate this.



Expressions for cardinality

When graphs are transcribed into textual structural definitions it is
important to express cardinality in a consistent way. Below is a
recommendation for such expressions:

|1:1 |exactly one |
|0:1 |may one |
|1:* |at least one |
|0:* |may several |

It is imperative that cardinality can be bi-directionally depicted in
graphs for definition purpose.


Specialisation

When a concept is specialised into sub concepts it is imperative that the
aspect of division is specified in the graph, together with notation of if
it is an extensive or non-extensive, overlapping or non-overlapping
specialisation, as well as any combination thereof.


Text formatting conventions

Concepts should be written in bold and relations should be written in
italics. Specialisations should be written in Arial, if Times is generally
used in the document, otherwise in some other differing font.


Available tools

The only terms and concept database made known to the working group -
compliant to the general functions and demands mentioned above - was
developed for the Stockholm County Council- SLL (regional health
authority). It exists on the intranet of SLL, and is also available at
www.terms.ks.se. It is based on a commercial, internationally available
application tool, suitable for the purpose.

A valuable source for the work of CEN/TC 251 is an Access database run by
Dr. B. Hayes as a working tool for a CEN/TC 215 Ad Hoc Group on terminology
containing some 915 terms and their verbal definitions, and versions from
different documents.


Proposal for a CEN/TC 251 Terms and Concepts database


Development tool

It is suggested that the terms and concept database tool used in the
Stockholm County Council is further developed to meet the intentions and
specification given in this Technical Report.

The development tool used is a commercial product, widely spread in
international companies. It is based on repositories that can be approached
in different ways, depending on which on top user application module
chosen. One of these is an UML module. An application tool for customized
solutions is also available, and with this a module for concept modeling
compliant to the demands above has been developed. From the repository web
pages can be generated by a few keystrokes.


Implementation

Since the input of terms, concepts and their relations collected from
various standard documents requests access to a customized module for this
purpose, it is preferable that the T&C-base is installed where support is
easily available. The database engine is free to choose from common
commercial products.


Maintenance

The maintenance of the T&C database requires a central management function.


The input of terms and concepts from existing sources (CEN/TC 251
standards) will be an extensive work initially, demanding knowledge of the
application and general knowledge in terminology.

For quality control reasons it is proposed that each working group should
be notified when the concepts from "their" work has been entered into the
database and given the task to verify correctness, especially important and
meticulous when graphic models are constructed for previously only
textually defined concepts. The working groups should also be given the
responsibility for continued monitoring and proposals for changes or
amendments to the relevant terms of their work.

It is proposed that when a new document (EN, TS or TR) has reached the
stage 32 First Working Document then a change request should be made to the
T&C management. Of course such early proposals should be indicated as such
in the T&C. At the stage of the CEN Enquiry and finally when ratified for
publication, further change requests should be made to the T&C correcting
previous versions. It is not the intention to keep all historic versions
but only the currently recommended versions of each concept. By marking a
concept status as `obsolete´ it is however possible to store old versions
and direct to its successor, when applicable.

In order to review the T&C management and resolve issues of conflicts
between the usages of terms from different working groups it is proposed
that a T&C Reference Group is established. This shall consist of a
Terminology representative of each working group, the WG II (Terminology)
convenor and secretary, and the TC chairman and secretary.

It is proposed that the management of the T&C operation is included in the
tasks for the CEN/TC251 secretariat, but it is recognized that the amount
of work, especially to establish the T&C initially requires that special
financial support is made available for this.


Proposal in summary

The proposed database described in this report is intended to be able to
serve, firstly the international work in the English language but can also
serve as an important facilitator of national implementations of CEN
standards. Finally, it should be pointed out that an updated and
comprehensive reference terminology of health informatics, especially if
available in multicultural/multilingual format, will be an important
facilitator for the development of the European market of IT products and
solutions for health that reach far beyond the standardisation process.

It is suggested that a T&C-base is developed according to the intensions
and specification given in this TR based on the terms and concept database
in the Stockholm County Council.

This should be implemented at the CEN/TC 251 secretariat managed by SIS -
Swedish Standards Institute and that the secretariat is given the task to
maintain it.
Annex A. (from STG, Swedish General Standards Group within SIS - Swedish
Standards Institute)

Functional demands on a web-based term- and concepts database


In order to create a good overview the demands are categorised as presented
in the table below. Note that some demands can belong to more than one
category.
Together with it's database capacity, the application will ideally also be
able to serve as a modelling tool generating web pages on demand.



|Category |Description |Code |
|Modelling support |Support for both individual|MS |
| |and guided modelling. | |
| |Effectiveness in work. | |
|Concept modelling |Demands on a tool to comply|S |
|notation language |with the definitions of a | |
| |concept modelling notation | |
| |language | |
|Working method |Compliance to defined |SM |
| |working method. | |
|Model |Handling of models outside |MA |
|administration |the real modelling work | |
|Publishing / |Via web, or electronic |P |
|distribution |documents | |
|Ergonomics |Eg. demands for a |E |
| |non-tiring working mode, | |
| |physically nor mentally | |
|Integration |Possibilities for |I |
| |integration with other | |
| |types of supporting systems| |
|Human factors |Learning, flexibility |M |
|Non-functional | |IF |
|demands | | |
|Organisation |Demands supporting |O |
| |organised modelling work, | |
| |eg. team based, distributed| |
|Basic demands on a|General, desirable |V |
|tool |characteristics | |

Some demands are more a desire for some specific technical solution, than a
demand for certain functionality. This is to be born in mind in the future,
when the final demands are made. "Pure" demands are marked K.


Modelling support

|Demand|Description |STG |Type |Comments |
|no. | |source |(mand/op| |
| | | |t) | |
| |Follow a semantic|Ref 1, |MS, S |A semantic model is |
| |model. Not only a|page 7 |mandator|(presumably) a meta |
| |drawing tool. | |y |model for language. |
| | | | |Tools that comply with |
| | | | |this demand have an |
| | | | |internal |
| | | | |representation of the |
| | | | |language and can |
| | | | |thereby give the |
| | | | |modeller support, e.g. |
| | | | |to control the syntax. |
| |Multi-user |Ref 1, |MS, E |Technical aspect. |
| |support. (K) |page 7 |mandator|The tool shall be |
| | | |y |possible to install and|
| | | | |configure centrally in |
| | | | |a network |
| |Multi-user |Ref 1, |MS, V, O|User aspect. |
| |support. (K) |page 7 | |Team based and |
| | | |optional|distributed modelling |
| | | | |with models in parts |
| | | | |possible to integrate. |
| | | | |The language itself |
| | | | |must support this. |
| | | | |Mainly for daily |
| | | | |professional use. |
| |Visible model |Ref 1, |MS |See demands 5, 6 and |
| |structure |page 8 |mandator|12. |
| |possible to | |y | |
| |navigate. (K) | | | |
| |Graphic search |Ref 4. |MS |When concept is found |
| |for concept in | |mandator|it shall be centred in |
| |diagram. | |y |the diagram window. |
| |Selectable |Ref 1, |MS |E.g. possibility to |
| |dimensions in |page 8 |optional|show only selected |
| |structure. (K) | | |hierarchies of |
| | | | |specialisation. See |
| | | | |demand 4. |
| |Multiple dialog |Ref 2, |MS |Writing and editing of |
| |boxes for text |page 4 |optional|definitions of multiple|
| |definitions open | | |concepts possible to do|
| |for parallel | | |in parallel sessions. |
| |editing on | | | |
| |demand. | | | |
| |Browser and |Ref 2 |MS |Two separate views to |
| |diagram views of | |mandator|look at the same model,|
| |the same concept | |y |which is stored only |
| |model. | | |once. |
| | | | |See also demand 4 and |
| | | | |5. |
| |Separate views of|Ref 2, |MS |I.e. a change in one |
| |model |page 4 |mandator|view will be seen in |
| |associated. (K) | |y |all other views. |
| |Direct and |Ref 2, |MS |See demand 1, 20 and |
| |influence layout |page 4 |mandator|28. |
| |of diagram. (K) | |y | |
| |Direct |Ref 2, |MS |See demands 9 and 28. |
| |arrows/bows |page 4 |mandator| |
| |points of | |y | |
| |attachment to | | | |
| |concept symbols. | | | |
| |(K) | | | |
| |References to |Ref 2, |MS, O |Modularised models. If |
| |other concept |page 4 |mandator|a concept is reused |
| |models be | |y |from an other model, |
| |supported. (K) | | |this should be |
| | | | |reflected in the |
| | | | |diagram where the |
| | | | |concept is shown. |
| | | | |On a higher level, the |
| | | | |links in between models|
| | | | |should be shown. |
| |Support for |Ref 2, |MS |Other defined concepts |
| |marked (e.g. in |page 4 |mandator|to be automatically |
| |bold) references | |y |identified by system |
| |in textual | | |and marked. |
| |definitions. (K) | | | |
| |The linkage in |Ref |MS |See also demands 9 and |
| |between bows and |2,page |mandator|10. |
| |objects to be |4 |y | |
| |sustained even if| | | |
| |objects are moved| | | |
| |in diagram. (K) | | | |
| |Reference to |Ref 4 |MS |I.e. reference to an |
| |external source. | |mandator|external document, |
| |(K) | |y |organisation etc. |
| |Conceal / show |Ref 4 |MS |Influences the |
| |attribute. (K) | |mandator|clearness of big |
| | | |y |models. |
| |Zoom function. |Ref 4 |MS |Selectable |
| |(K) | |mandator|magnification of model,|
| | | |y |possibly stepwise. |
| |Editing in dialog| |MS |Temporary editing boxes|
| |boxes. (K) | |mandator|showing on clicking at |
| | | |y |object. |
| |Editing directly | |MS | |
| |in graph. (K) | |optional| |
| |Textboxes to |Ref 4 |MS, E |Facilitates the work. |
| |adjust to length | |mandator| |
| |of text. (K) | |y | |
| |Catalogue with |Ref 4 |MS |Links are concepts |
| |types of links. | |mandator|themselves, to be |
| |(K) | |y |defined. |
| | | | |The types are yet to be|
| | | | |identified. SeLiM work |
| | | | |item is devoted to this|
| | | | |task. |
| |Control of |Ref 4 |MS | |
| |consistence on | |mandator| |
| |demand. (K) | |y | |
| |Visual |Ref 4 |MS |. |
| |demonstration of | |mandator| |
| |differences in | |y | |
| |content in | | | |
| |between two | | | |
| |versions of a | | | |
| |concept model. | | | |
| |(K) | | | |
| |Pre-view at |Ref 4 |MS |Markings in diagram of |
| |printing | |mandator|extension of pages. |
| | | |y | |
| |Printing format |Ref 4 |MS |Fully support of system|
| | | |mandator|functions for printing.|
| | | |y | |
| |Sizeable print |Ref 4 |MS |Size of page adjusts to|
| | | |extra |chosen format. No |
| | | | |objects cut at edges. |
| |Marking of print |Ref 4 |MS |Marking of area for |
| |area | |extra |printing possible |
| |Automatic layout |Ref 4 |MS |Automatic detection of |
| |on demand. (K) | |extra |optimal layout of |
| | | | |diagram. See demand 10 |


Concept modelling notation language

|Demand|Description |STG |Type |Comments |
|no. | |source |(mand/op| |
| | | |t) | |
| |Handle both |Ref 2 |S |I.e. not only a graphic|
| |graphical and |page 2 |mandator|modelling tool, but |
| |textual notation.| |y |integrating textual and|
| |(K) | | |graphical elements. |
| |Handle graphical |Ref 2, |S |This includes |
| |elements as |page 3 |mandator|representation of |
| |defined in the | |y |cardinalities. |
| |notation | | | |
| |language. (K) | | | |
| |Support the |Ref 2, |S | |
| |syntax for |page 3 |mandator| |
| |attributes as | |y | |
| |defined in the | | | |
| |notation | | | |
| |language. (K) | | | |
| |Graphical support|Ref 2, |S |I.e. super-ordinate, |
| |for types of |page 3 |mandator|subordinate, |
| |specialisation of| |y |complete, non-complete,|
| |concepts as | | | |
| |defined in the | | |overlapping, |
| |notation | | |non-overlapping |
| |language. (K) | | | |
| |Arrowheads on |Ref 4 |S |This facilitates the |
| |links. (K) | |mandator|understanding of what |
| | | |y |is the defining |
| | | | |direction of a link, |
| | | | |and what is it's |
| | | | |inverse. |
| |Textual |Ref 2, |S |The graphical model |
| |definitions to be|page 4 |mandator|shall have an textual |
| |linked to the | |y |interpretation |
| |graphic symbols. | | |according to a defined |
| |(K) | | |syntax. |
| | | | |See demand 23. |


Working method

|Demand|Description |STG |Type |Comments |
|no. | |source |(mand/op| |
| | | |t) | |
| |Open and defined |Ref 1, |SM, I, V|Application Programming|
| |interface to |page 8 | |Interface for |
| |other systems. | |mandator|integration with other |
| |(API). | |y |tools and access to the|
| | | | |database content. |
| |Conversion in |Ref 2,|SM |What languages are of |
| |between simple |page 4 |mandator|interest except for |
| |notation language| |y |UML? EXPRESS ? |
| |and UML. (K) | | |What directions? |
| |Export to other |Ref 2 |SM, I |E.g. MS Word, simple |
| |applications. | |mandator|vector graphic appl., |
| | | |y |data modelling tools |
| | | | |etc. |
| | | | |See demand 35. |
| |Report generator.|Ref 4 |SM, P |E.g. reports generated |
| |(K) | |optional|from the graph. |


Model administration

|Demand|Description |STG |Type |Comments |
|no. | |source |(mand/op| |
| | | |t) | |
| |Meta model |Ref 3, |S |Rev. versions possible |
| | |page 1 |mandator|to support. |
| | | |y |See demand 1. |
| |Handle status of |Ref 1, |MA |E.g. EN, TS, TR, |
| |models. (K) |page 8 |mandator|working mtrl, etc. |
| | | |y | |
| |Handle versions. |Ref 4 |MA, MS |Traceable changes at |
| |(K) | |mandator|conversion into UML or |
| | | |y |otherwise edited |
| | | | |versions |
| |Version |Ref 4 |MS |Presentation of |
| |comparison. (K) | |mandator|differences in between |
| | | |y |versions |
| |Access control to|Ref 3, |MA | |
| |versions. (K) |page 2.|mandator| |
| | | |y | |


Publishing / distribution

|Demand|Description |STG |Type |Comments |
|no. | |source |(mand/op| |
| | | |t) | |
| |Presentation |Ref 1, |P, E |Working interface be |
| |interface be |page 8.|mandator|Windows and/or platform|
| |platform | |y |independent web. |
| |independent web. | | | |
| |(K) | | | |


Integration

|Demand|Description |STG |Type |Comments |
|no. | |source |(mand/op| |
| | | |t) | |
| |Import /export |Ref 1 |I, SM |Complete or part of |
| |functions. (K) |page 8.| |model. Format to be |
| | | | |determined. |
| |Repository based |Ref 3, |I, | |
| |database |page 2.|mandator| |
| |solution. | |y | |


Ergonomics

|Demand|Description |STG |Type |Comments |
|no. | |source |(mand/op| |
| | | |t) | |
| |Easily, |Ref 1, |E, M, MS|Subjectively judged |
| |intuitively used.|page 7 | | |
| |(K) | | | |
| |Easy to add data.|Ref 1, |E, MS |Subjectively judged |
| |(K) |page 7 | | |



Human factors

|Demand|Description |STG |Type |Comments |
|no. | |source |(mand/ | |
| | | |opt) | |
| |Flexibility (K) |Ref 1, |M, |Adjustable to new needs|
| | |page 9 |optional|and |
| | | | |development/learning |


Organisation

|Demand|Description |STG |Type |Comments |
|no. | |source |(mand/ | |
| | | |opt) | |
| |Unique concept ID|Ref 6. |O |Together with literal |
| | | |mandator|(e.g. XML tag) |
| | | |y | |


Non functional demands

|Demand|Description |STG |Type |Comments |
|no. | |source |(optiona| |
| | | |l) | |
| |Adequate pricing |Ref 4. |IF |. |
| |Support |Ref 4. |IF |Training, |
| | | | |documentation, |
| | | | |upgrading |
| |Local |Ref 4. |IF |In concerned countries.|
| |representation. | | | |
| |System demands. |Ref 4. |IF |No exceptional system |
| | | | |demands. |
Annex B. Semantic meta model

(by Sven-Bertil Wallin)


[pic]

Figure 1 Semantic model version 2001-01-15
15 60 60 42
A semantic model for terminology

On a conceptual level, the model describes the metaconcepts needed for a
representation of a terminology. These metaconcepts can be implemented in a
tool intended to hold a concept system. The model is strictly conceptual
and must be enhanced with information needed for handling of graphical
presentation, versions, history and other technical aspects.

The model has two parts, one describing how concepts are defined and
presented by their relations.

A Concept17 can be a Core Concept, describing an actual thing in the real
world (i.e. Activity) or a Type Concept describing a type of thing, i.e.
Activity Type.
The concepts are related to each other via Concept Relation196 s. These can
be of four different types: Generic Relation146 , Ontologic Relation19 ,
Synthetic Relation200 and Type Relation214 .
The most important type is Ontologic Relation19 that defines a concept by
relating it to other concepts. Semantic model15 s are associations possible
to perceive as categorial structures in the real world. These will be
further categorized and defined in the CEN/TC251 SELIM work item.
Generic Relation146 represents traditional classifications, by showing
relations between specialized concepts and generic concepts.
Synthetic association20 s are not necessarily shown in graphs as
associations. One such type is employed when grouping concepts into
"Subject areas" or "Semantic categories" by showing an interrelation of
concepts in fields i.e. Nursing. Type Relation214 is the relation between
a Core Concept and a Type Concept, i.e from Activity to Activity Type.

The other part of the model describes how these concepts are used and how
they can be referred by terms. One concept must have at least one Term
usage18 pointing at one Term16 . This Term usage18 is referenced by one
or more Term Usage Reference48 which connects a certain term usage to a
User52 .

Term Usage reference48 also describes in what way a user52 uses the
term16 and concept17 . It also shows which Concept Relation196 s is used.
The User52 is in this model a very broad definition, a user can be a
person, an organization, a specific document or a model.



Annex C. Explanatory comments to Figure 1.


The figure is intended to clarify the working process for development of
enterprice supporting datasystems, based on an existing activity in need
for computerization.

It starts with perceived needs for improvement. These are formulated into
specified needs and specified objective with the intended work, sometimes
taking the form of an objective model.

This delimits the area of the present enterprise to be analysed into a
process model. If the described process is not optimal (which rarely is the
case), it will be remodelled into a target process model, directed by the
specified objective.

From the catch of terms used in the present enterprise a selection is made,
directed by the needs of the target process, and new terms are added to a
term list, when needed to describe the new process. The meaning of these
terms is defined in a concept analysis, presented in a concept model. The
concepts and their mapped terms are stored in a terms and concept database,
comprising the terminology of the application.

The process model with it's terminology are then moulded together into the
data model, further developed into the system model and programmed into the
first prototype. This will then be tested and revised in an incremental
process, resulting in the application product.

It is important to notice that professionals from the floor will be heavily
involved in all steps leading to the data model, as well as in the testing
of the prototypes. These parts are marked in yellow in the graph.
Annex D. Example : Definitions of concepts for healthcare, from a
healthcare record perspective

|Term |Concept definition |Graph |
|actor |Descriptive definition |[pic] |
| |physical person in a certain role | |
| |(IA-SLL-SäK01) | |
| |Structural definition | |
| |physical person in a certain role (IA-SLL-SäK01) | |
| |who | |
| |initiates at least one patient related contact | |
| |receives at least one care message | |
| |Some actors has specified professionalism. Actors | |
| |can be either hc actor, | |
| |patient or patient related actor. | |
| |Comments | |
| |Actor is defined in IA-SLL-SäK01 as | |
| |physical person in a certain role | |
| |Relations | |
| |Actor refers to exactly one physical person | |
| |Actor adopts exactly one role | |


-----------------------
[pic]