National foreword

This Published Document has been prepared by Technical Committee IST/35 and is identical with CR 12161 : 1995 A method for defining profiles for healthcare published by the European Committee for Standardization (CEN).

Compliance with a British Standard does not of itself confer immunity from legal obligations.

Committees responsible for this Published Document

The preparation of this Published Document was entrusted to Technical Committee IST/35, Medical informatics, upon which the following bodies were represented:

Association of Anaesthetists Great Britain and Ireland

BCS Nursing Specialist Group

British Computer Society

British Computer Society (Health Informatics Specialist Groups)

British Medical Association

British Nuclear Medicine Society

College of Radiologists (Clinical Oncology)

Computing Services and Software Association

Conference of Royal Colleges Information Group

Department of Health

Electro Medical Trade Association Limited

Faculty of Public Health Medicine of the Royal College of Physicians in the UK

Institute of Medical Laboratory Sciences

Nine Tiles K-net

Management Consultancies Association

National Health Services

NHS (Information Management Centre)

Royal College of Surgeons of England

Simpler Trade Procedures Board (Sitpro)

Society for Computing and Technology in Anaesthesia

This Published Document, having been prepared under the direction of the Information Systems Technology Assembly, was published under the authority of the Standards Board and comes into effect on 15 May 1996

The following BSI references relate to the work on this standard:

Committee reference IST/35

This CEN REPORT has been adopted by Technical Committee CEN/TC 251, Medical informatics, and has been approved by CEN on 1995-08-17.

CEN members are the national standards bodies of Austria, Belgium, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Italy, Luxembourg, Netherlands, Norway, Portugal, Spain, Sweden, Switzerland and United Kingdom.

1. INTRODUCTION

This is the second edition of EWOS Technical Guide ETG 021. The first edition was produced by EWOS/EG MED as the first step in fulfilling a number of Mandates issued by the Commission of the European Communities. The Mandates concerned the production of profiles in the healthcare field. This Technical Guide defines a method for identifying such profiles. This second edition is a revision of the first, incorporating changes to the method which were identified by EWOS/PT N024 on medical image interchange, the first time the method had been used fully in one application area.

There are a number of audiences for this document. The principal one is practitioners in the field of IT in healthcare (e.g. the IT manager at a hospital). Others include suppliers of IT products and, to a lesser extent, OSI experts assisting in healthcare procurement etc.

1.1 BACKGROUND

In 1989, SOGITS issued Mandate BC-IT-SI-05. This Mandate was split into two parts, one being the responsibility of CEN and the other of EWOS. Both organisations set up Project Teams and both teams reported in early 1991. The report of EWOS PT 007¹ provides useful background to this Technical Guide. EWOS/TA 13 agreed that a new Expert Group (EG MED) should be set up in order to undertake work within the field of healthcare that falls within the remit of EWOS. The Work Programmes proposed by both PTs have been incorporated into a single document which has been approved by the CEN BT². All aspects of this Work Programme that are concerned with Open Systems are the responsibility of EWOS/EG MED. Specifically, five items of the Work Programme have been so identified at the present time:

3.1	OSI Application Profiles for HealthCare
3.2	OSI Transport Profiles for Health Care
3.3	OSI Management Profiles for Health Care
3.4	Multimedia Medical Data Interchange
4.1	Functional Profiles for Medical Image Interchange
4.7	Medical Image Interchange: Conformance Testing of Standards Implementations

The CEC has issued mandates in respect of work items 3.1 and 4.1. The first five work items are concerned with profiles, the last with conformance testing (and hence will be handled separately at a later date).

This document provides a description of the method for mapping user requirements into open systems (principally OSI) profiles.

1.2 OBJECTIVES

The principal objective of this document is to define a method whereby "real world" user requirements for communication between healthcare systems can be mapped on to open systems profiles.

There is a myriad of requirements for information interchange and processing in healthcare and these requirements may be satisfied by many different combinations of profiles. Current OSI profiles are well defined and categorised^3,4; user requirements are neither well defined nor categorised, although work is being undertaken within CEN which will assist in this respect.

Most OSI profiles have been defined to support a specific interworking requirement and have not been used to satisfy the needs of any particular domain. When the user requirements are mapped onto existing profiles, there are three possibilities:

Therefore, this document is intended to specify a method for:

It is impractical to map every user requirement on to the appropriate profiles, as the set of user requirements is potentially extremely large. Instead. the document defines a method of specifying user requirements in a systematic manner so that classes of functionally similar user requirements can be mapped onto the same profiles.

In addition, at present there are no healthcare specific OSI base standards (as exist in other application areas such as manufacturing and inter-library loans). When such standards are developed (through bodies such as CEN), then profiles may also be required.

This document does not undertake the required profiling work. However, it does define a general method which will allow the profiling work to be undertaken (and thus fulfils the initial part of the first four work items specified above).

Further work will be required in future, particularly to relate user requirements to OSE profiles when these are developed.

1.3 DEFINITIONS

In this document, it is hoped that the meaning of the terms used are intuitively obvious. However, it is necessary to use terms precisely and so some formal definitions are given here. A list of acronyms is given in the Glossary.

Attribute: A property of a real-world object which can be characterised by a set of values. A set of attributes is selected in order to enable the characteristics of a particular domain to be enumerated. The particular domain of interest in this report is that of information interchange. Other domains (for future study) include Security, Information Structure, etc.

Attribute Value: A set of possible values which is assigned to a given attribute (e.g. attribute "Volume" may take the value "Small"). Attributes and their values are selected to be meaningful to non-IT specialists, and intuitive to apply.

Set of Attribute Values (SAV,): For a defined set of attributes corresponding to a particular domain of interest (e.g. medical imaging), a Set of Attribute Values consists of an (ordered) list of values for each attribute.

"Goodness of Fit Factor"(GOFF): This defines how well a particular profile (or set of PFCs) matches a particular Set of Attribute Values.

Profile Functional Characteristics (PFCs): These characterise, in user-orientated terms, the functionality supported by a profile (or base standard). In many cases, PFCs will correspond to optional profile features which may need to be made mandatory in order to satisfy a particular user requirement (e.g. body part in MHS, document type in FTAM).

User Scenario (US): A description of a real-world information processing requirement, which may be characterised by a unique Set of Attribute Values. The relationship of US to SAV is many to one.

User Scenario Characteristic (USC): An aspect of a User Scenario that can be defined for a given scenario in such a 'way as to facilitate mapping on to an Attribute Value

1.4 STRUCTURE OF THIS DOCUMENT

Chapter 2 is a summary of the method; it is intended that this Chapter should be included in all documents which use the method, in order to give a consistent, brief outline. Chapter 3 defines the approach and the method adopted to map the user requirements to profiles. Chapter 4 demonstrates how the user requirements are categorised and the Attributes determined. The next Chapter assigns values to the attributes relevant to healthcare information interchange and defines how attribute domains relate to typical user scenarios. Chapter 6 briefly examines the open systems profiles and their categorisation. Chapter 7 defines the "Goodness of Fit Factors" and discusses their values. Chapter 8 specifies the matrix thus derived and this is followed by Conclusions and Recommendations. Finally, there is a Glossary and a list of References.

2. SUMMARY OF METHOD

3. APPROACH AND METHOD ADOPTED

3.1 INTRODUCTION

Information systems are rapidly becoming an accepted part of the healthcare world. As further systems are installed the need to pass information between them becomes greater, and the main obstacle preventing this is the lack of suitable and accepted communications standards.

Obviously many OSI standards can be used for such communication, but little work has been done on the suitability of OSI profiles for particular healthcare applications. Specifically, few attempts have been made to categorise rigorously which profiles should be used to satisfy which user requirements.

This document attempts such a categorisation by building a matrix of user requirements against OSI profiles, or to be more exact, a matrix of user scenarios against profiles. An entry would then be made at the cell representing the intersection of the scenario with a particular profile to indicate the suitability of the profile in that situation. It should then be a simple matter for the user to identify a particular scenario on the y-axis of the matrix and look along the line of cells for suitable profiles. Given that more than one profile would be suitable, the user could decide which to use based on his own implementation constraints. For example, he might be constrained by cost or an existing network.

Thus, at its simplest, the matrix would be of the form:

No alternative text available for this inline-text image

However, healthcare informatics is a very wide subject which covers a large number of complex medical areas. It therefore gives rise to an almost infinite range of user scenarios. Although it is theoretically possible to identify these, there are certain disadvantages:

Specialist medical knowledge would be required
The resulting matrix would be huge and unmanageable
It would be difficult to insert new scenarios or profiles into the matrix

Thus, while the above proposal would fulfil the requirement of identifying the mapping between user scenarios and profiles, it could not be used in practice. Therefore a method needs to be found to classify the scenarios in such a way that the matrix becomes manageable and which will allow interested parties to determine which profile(s) could - or should - be used for a particular user scenario. This imposes certain limitations on the exact structure and terminology used in the matrix. In particular, the following need to be borne in mind:

This document is intended to be used by domain experts (probably healthcare IT specialists) rather than OSI experts.
Although intended primarily for use in Europe it should be accessible to and able to accommodate contributions from experts in other countries.
The purpose of this document is not necessarily to define unequivocally the profile that should be used for a particular scenario, but to point the user towards a number of profiles that could be used (or, put another way, will permit the user to discard profiles that are not suited to that particular scenario). It will then be up to the user to decide which profile to use, depending on the particular combination of functionality, cost, performance etc. that is required.

This approach has certain important effects:

•	The terminology used, although applied in a rigorous manner, is biased towards that used in the user community rather than by OSI experts.
•	The choice between certain profiles is determined by factors outside the scope of this document. For example, a user may require to send a file between two remote machines and the matrix may indicate that both FTAM and MHS are suitable. To an OSI expert, there are obvious differences in the use of these profiles. However, it is difficult to specify these differences as part of the user scenario, and therefore the scenarios that require MHS and FTAM cannot be segregated. The matrix would indicate both profiles to be suitable and the user should consult an OSI expert in order to come to a final decision.
■	There are a number of non-OSI standards either being developed or in use in the healthcare domain (e.g. DICOM⁵). It is likely that if their functionality is not matched by an existing OSI profile, a new non-OSI profile may be required (this is permitted in TR 10000). For this reason, such profiles are included in the matrix.

3.2 REFINEMENT OF METHOD

3.3 SELECTION OF ATTRIBUTES

3.4 WORKING METHOD

3.5 ELABORATION OF WORKING METHOD

4. DERIVATION OF ATTRIBUTES FOR HEALTH CARE INFORMATION TRANSFER

4.1 INTRODUCTION

As stated previously, the Attributes and their values can be selected in many different ways, although principles for their selection were discussed in Chapter 3. The purpose of this Chapter is to specify the Attributes used in this method. The next Chapter specifies the Values of those Attributes.

There is a multiplicity of information objects in the field of healthcare. However, it is not necessary to identify all the objects that may be the subject of communication as many will take a form that is sufficiently similar for their differences to have no apparent effect on the transmission mechanism. For example, both PATIENT and LOCATION are object classes, but intuitively there is no reason why they should be treated differently during the transmission process, unless they have different attributes.

Therefore, it is sufficient to define the attributes at a level below which the sub-types would have no apparent effect on the Profile used.

4.2 EXAMPLES OF HEALTH CARE INFORMATION OBJECTS

4.3 ATTRIBUTES IDENTIFIED

4.4 DERIVED ATTRIBUTES

4.5 SECURITY ATTRIBUTES

4.6 MANAGEMENT ATTRIBUTES

5. ATTRIBUTE VALUES

5.1 INTRODUCTION

For each of the Attributes identified, a range of Values need to be selected. In some cases, the Values are obvious. In others, a choice is possible; in such cases, the Values chosen are those which assist most in selecting the appropriate Profile(s).

5.2 DERIVATION OF ATTRIBUTE VALUES

5.3 EXAMPLES

6. OPEN SYSTEMS PROFILES

6.1 INTRODUCTION

So far, we have described one axis of the matrix - that concerned with the user requirements. This Chapter briefly examines the other axis, that concerned wi1h profiles. In many ways, this is considerably less complex in that this has already received a great deal of attention and is the subject of an ISO/IEC Technical Report (TR 10000). That document defines a framework and taxonomy of profiles and thus forms the basis of the current document.

6.2 1SO/IEC TR 10000

6.3 HYBRID PROFILES

6.4 DIVISION OF THE X-AXIS INTO H, F, A AND T-PROFILES

7. GOODNESS OF FIT FACTORS

7.1 INTRODUCTION

The purpose of the Health Care matrix is to determine how user requirements map into profiles. At its simplest, this means determining whether a requirement is fully satisfied by a profile. However, it is very unlikely that there will be a complete match and so, as explained previously, it is necessary to determine how well a profile matches the requirements.

This has been designated the "Goodness Of Fit Factor" (GOFF) and is explained in more detail in this Chapter.

The following table lists the GOFFs that have been assigned.

7.2 DISCUSSION OF SPECIFIC GOFF VALUES

8. THE HEALTH CARE MATRIX

8.1 INTRODUCTION

This Chapter demonstrates how the healthcare matrix is developed and populated.

In brief, the process is as follows: take a User Scenario, derive its SAVs, map to the various profiles, apply the GOFF assignment rules and enter into the table. Repeat for each User Scenario.

In order to achieve this, due to the number of scenarios and the complexity of the problem, a more compact form than the ones given above as examples is required and the abbreviations already introduced serve this purpose (see Annex B).

In order to derive the SAVs, it is convenient to use a tabular form as shown below, then to concatenate the Values to produce the relevant SAV. Various representations may be used. When showing a number of SAVs, the most convenient representation is in tabular form as shown in the following pages; when showing a single SAV, the most appropriate representation is by key. For example, for the first scenario on the following page, the representation would be:

Thus, to reiterate the method, it is the intention to generate a matrix. The horizontal axis consists of the taxonomy of TR 10000, perhaps with additions. The vertical axis consists of the SAVs which have been identified by means of defining the Attribute Values for various scenarios.

In what follows, fourteen different scenarios have been used and only the Transport Profiles considered. Extension of the matrix is considered later.

No alternative text available for this inline-text image

Having deduced the SAVs from the scenarios. they are examined to determine whether any are duplicated and, if so, the duplicates eliminated (none in the above scenarios). These then become the vertical axis of the matrix. The elements of the horizontal axis in this partial matrix are the T-profiles defined in TR 10000.

Each cell in the matrix (i.e. the intersection of a SAV and a profile) is then examined to determine how well the profile (or, more accurately, the Profile Functional Characteristics - PFC) fits the user requirement (its GOFF, as defined previously). This is achieved by defining the PFC for each Profile, then defining the relevant GOFF assignment rules using the precedence rules outline previously.

As an example, consider profile TX51 (LAN, CSMA/CD). It has a nominal data rate of the order of 10 Mbit/s; it permits direct or networked connections and is used in a local environment (DISTANCE attribute).

Thus the following GOFF assignments may be deduced:

Applying the above methods leads to the final matrix. An example of part of this matrix for the example given above is shown on the next page.

8.2 MAINTENANCE AND EXTENSION OF THE MATRIX

8.3 USE OF THE MATRIX

9. SUMMARY AND CONCLUSIONS

9.1 SUMMARY

9.2 CONCLUSIONS

9.3 RECOMMENDATIONS

REFERENCES

PD 6589:1996

A method for defining profiles for healthcare

Current

Published:

15 May 1996