EIM Home

An Overview of the
Department of Health (DOH) WA
Enterprise Information Model (EIM)

Acknowledgement
The Basics
What is an Information Model?
Why do we need an Enterprise Information Model?
What is the copyright position of the DOH WA EIM?
Using the EIM
Use by the DOH WA
Use by Health Professionals
The Scope of the DOH WA EIM
Corporate Meta Data
How were the DOH WA EIM and BAIM Developed?
What is included in the EIM?
What is not included in the EIM?
What medium is used for documenting the EIM and its Dictionary?
The Context of the DOH WA EIM
What is the relationship between the EIM and the Enterprise Architecture?
What is the relationship between the EIM and subsidiary models?
How is the EIM related to the National Health Information Model?
Modelling and Documentation Standards
Entity Relationship Model (ERM)
Entities
Super-type/Sub-type Entities
Relationships
Recursive Relationships
Subject Areas and Business Areas
Relationship to DOH WA Information Subject Group Model

Acknowledgement

Much of the material in this overview is taken directly, or derived, from the document A Guide to the NSW Health Enterprise Information Model produced by the Information Architecture Group, NSW Health. The document is part of the supporting documentation for the NSW Health, EIM Version 2, 1996.

Our appreciation is also extended to the Information Architecture Group, NSW Health for their support and assistance in the development of the DOH WA EIM.

The Basics

What is an Information Model?

Town planners often represent their vision for a new town or suburb using diagrams drawn to recognised conventions. The resulting town plans are intended as a framework within which detailed plans for individual buildings can be specified. The Department of Health Western Australian (DOH WA) Enterprise Information Model (EIM) is the "town plan" for the information that supports the business of public health in WA. From this, detailed specifications for computer software can be drawn up, analogous to developing detailed designs for buildings and services to fit into a town plan.

During the course of providing health services to our clients, there is nearly always a need to maintain a record of what has been done. In some instances, plans are recorded of what services are to be provided to a client. Instructions or orders to other parties as well as their responses (test results, diagnoses, images, etc.) usually need to be recorded. All of these things may take the form of numbers and/or text, pictures, images, and sound. Information is often recorded on paper or film as well as being held in computer files. Information used or generated in the business of health is very diverse.

The usual means by which we can bring some order to this diversity and complexity is by establishing standard definitions for terminology, particularly the labels we apply to information. Typical labels within the Health industry include `Episode of Care', `Service Event', `Diagnosis', `Health Professional' etc.

The relationships between things also need to be documented. As a specific example, a data dictionary definition for a `Diagnosis' may include, "A diagnosis is made by a health professional and is the result of a health assessment".

Such facts about the business can of course be expressed in text (as is done in the example above), however we then run the risk that some important facts or concepts may become buried in volumes of words.

Over the last several years, diagramming notations have evolved whereby information or data and the relationships between them can be expressed as pictures. These pictures are called information models (or data models or entity-relationship models or some other model name) and are drawn to some very simple but meaningful rules. These models are in concept similar to those that a town planner produces for representing the layout of a new town or suburb. Because the rules and notations are straightforward and easily understood, the risk of misinterpretation is minimised.

Therefore an `information model' is a picture which represents the various types of information that are required within the domain being modelled. An information model also illustrates how information is inter-related. The objects in an information model are supported by text in a data dictionary.

The information that is held in information models, data models and data dictionaries is called meta data, that is, data about data. In other words meta data is information, usually documented in IT tools, that improves both business and technical understanding, of data and data-related processes.

The following diagram is part of one of the subject area diagrams from the EIM (Version 2.1), reproduced here to illustrate the style of the model drawn for the DOH WA:

Service Events Insert
..\e2-1_rab.htm#17904 ..\e2-1_res.htm#17817 ..\e2-1_rab.htm#17753 ..\e2-1_rab.htm#17888 ..\e2-1_rab.htm#17787 ..\e2-1_hrs.htm#17545 ..\e2-1_rab.htm#17897 ..\e2-1_sev.htm#17909 ..\e2-1_pty.htm#17357 ..\e2-1_sev.htm#21975 ..\e2-1_rab.htm#17886 ..\e2-1_sev.htm#17995 ..\e2-1_sev.htm#17976 ..\e2-1_sev.htm#18024 ..\e2-1_sev.htm#17969 ..\e2-1_sev.htm#17603 ..\e2-1_sev.htm#17804 ..\e2-1_sev.htm#17890 ..\e2-1_sev.htm#17517 ..\e2-1_sev.htm#18009 ..\e2-1_pty.htm#17383 ..\e2-1_sev.htm#21973

(Each box is used to represent a type or groups of information, each line linking boxes represents business relationships between the types of information, and the phrases against the lines represent descriptions of the business rules).

Why do we need an Enterprise Information Model?

The EIM exists:

What is the copyright position of the DOH WA EIM?

Users of the DOH WA EIM should be aware that a copyright on the NSW Health EIM, on which it is based, is held by the NSW Health Department. However the NSW Health EIM document or portions of it may be copied provided appropriate acknowledgement is made to Information Architecture Group, NSW Health, EIM Version xxxx where xxxx is the version date that appears in the source document which is copied.

The Department of Health (DOH) holds the copyright for the DOH WA EIM, where it is not a direct replication of the NSW Health EIM. Similarly, the document or portions of it may be copied provided appropriate acknowledgements are made.

The DOH WA cannot be held responsible for consequences resulting from the use of the EIM, as for example in the development of an information system based on the EIM or a portion of it. NSW Health also accepts no responsibility for consequences resulting from the use of the NSW Health EIM.

Using the EIM

Generally the EIM represents definitions and business rules for information specific to the business of health that is the responsibility of the DOH WA. Potential `users' of the EIM are:

Maintenance, distribution and change of EIM are managed centrally by the Consultant Corporate Meta Data located within the Health Information Centre (HIC) Health Information Planning Unit (HIPU). Use of the EIM will be distributed throughout the organisation and in some instances, such as information systems planning, development and package selection, that use may be a matter of policy.

Representation of the EIM and associated information to external bodies such as the Australian Institute of Health and Welfare, the National Health Data Committee and Vendor organisations will be the responsibility of the Manager of the Health Information Planning Unit at the Department.

Refinement of the EIM will be an ongoing process. To facilitate this, feedback channels to the Consultant Corporate Meta Data will be in place for all types of users both internal and external to the Department of Health WA. All users of this EIM are invited to participate in the ongoing refinement and extension of the EIM and supporting documentation. The Consultant Corporate Meta Data reporting to the Corporate Meta-Data Advisory Group (CMAG), is responsible for changes to the EIM. However, a change request to the EIM can be initiated by anyone within the DOH. The procedures for maintaining the EIM are outlined in the EIM Management Guidelines.

Additionally, the HIPU will provide any reasonable advisory and support services to users with the objective of promoting understanding of the EIM. However, resources are limited and priority will be given to internal users based on CMAG determined priorities.

The CMAG is made up of business and technical representatives from the Department of Health Corporate Divisions, Health Services and the InfoHEALTH Alliance.

Use by the DOH WA

Use by Health Professionals

Health Professionals (such as doctors, nurses, allied health workers, health information managers, administrators etc) are not expected to be direct users of the EIM, but their contribution to the development and content of the EIM and their endorsement of it will be invaluable.

Health professionals are the subject matter experts and as such they can:

The Scope of the DOH WA EIM

Corporate Meta Data

The DOH WA EIM is part of the corporate meta data, which is made up of the Enterprise Information Model (EIM), the Business Area Information Models (BAIM), which are the next level of specialisation in the model hierarchy, and the WA Health Corporate Data Dictionary (WAHCDD).

A project to develop the corporate meta data was initiated in June 2000. The project was divided into two stages, the first stage being the development of the EIM and the second stage being the development of the more detailed Business Area Information Models and the WAHCDD.

How were the DOH WA EIM and BAIM Developed?

The DOH WA EIM Project Control Group made a decision to utilise an existing Health Enterprise Information Model, rather than undertake green-field development in isolation. After conducting a search for these products it was determined that the best fit to requirements was the NSW Health Enterprise Information Model.

The project team, consisting of staff from the Health Information Planning Unit of the Health Information Centre and consultants from the InfoHEALTH Alliance led by DMR, conducted a series of workshops to review the model.

The workshops were attended by individuals who had both a knowledge of the business and an understanding of information modelling techniques, as the purpose was to review the existing model rather than identify DOH WA information requirements. To acquire this mix of skills, representatives were, on the whole, analysts or IS professionals from the Health Department of WA, the InfoHEALTH Alliance, Metropolitan Health Services, and the Rural Business Systems Unit.

The resulting model was published as EIM Version 1.0.

A second series of workshops where then conducted with Business Area representatives to identify more detailed information requirements and develop the next level of detail of the model hierarchy, the Business Area Information Models (BAIM). The BAIM were then used to "reengineer" the EIM into a WA specific model. This EIM and the BAIM were then published as Version 2.0.

The current Version 2.1 is the first release of the EIM under change control and is the result of changes requested to better meet the business requirements of Corporate Finance and the data collected and reported to the Commonwealth by the Health Information Centre (HIC). The Accounts subject area has been simplified based on feedback from the Corporate Finance Division in regard to the DOH Accounts structure and also to remove redundant relationships. Several changes have been made within the Service Events subject area, as Version 2.0 of the model did not adequately cater for information held within the public health system in regard to patient contact which occurs outside the public health system, but is reported to the DOH for consolidated reporting to the Australian Department of Health and Aging.

The most significant areas of difference between the NSW Health Model and the DOH WA model include:

What is included in the EIM?

The EIM has been partitioned into ten topics called subject areas. These "pictures" are intended to provide at least a standard framework of information for the `core' information of the DOH WA. The model does not capture every last detail of every possible information type that any practitioner or administrator may come across in their day to day work, nor is this its intent.

The EIM focuses on core business processes and their information needs. The EIM includes "object" definitions and relationships for information relevant to:

What is not included in the EIM?

It is not practical to incorporate every possible information type that any health worker or manager may come across in their work within the EIM. Indeed the value of such detail, even if derivable, is questionable. The corporate meta data allows for such detail to be maintained in subsidiary models, limiting the necessity for large scale change to the EIM.

Therefore the EIM does not include the following:

What medium is used for documenting the EIM and its Dictionary?

A master repository of the data model is maintained using the System Architect software from Popkin Software. This software is accessible only by the Consultant Corporate Meta Data and the EIM Project Team.

The documentation made available on this website is in large part generated programmatically from the master repository. Other components of the documentation are maintained using Microsoft Word, Microsoft Visio and Microsoft Front Page. Printable versions of this documentation are made available as Adobe Acrobat .pdf files, downloadable from this website.

The Context of the DOH WA EIM

What is the relationship between the EIM and the Enterprise Architecture?

The InfoHEALTH Alliance has produced the DOH WA Enterprise Architecture. The purpose of the Architecture is to create an optimal structure of applications and information to support DOH WA work processes using efficient technology. This architecture is presented under the four major headings of Work Processes, Information, Applications and Technology. The EIM meta data is the definitional framework of DOH WA information, which fits into the wider information management framework of the Architecture.

What is the relationship between the EIM and subsidiary models?

The EIM is an integrative model as it serves to represent and co-ordinate all the facets of health information development and management. This is achieved through a process of alignment and integration of subsidiary models (lower level, more detailed business area and application specific information models) with the EIM and recording of how the models "map" to one another.

The mapping of subsidiary models to the EIM is only performed for the logical model of the system, not the physical model that underpins it. The diagram above illustrates this relationship in a generalisation/specialisation hierarchy.

For any entity represented in a subsidiary logical model a number of possibilities exist to determine its mode of representation in the EIM. Firstly, the entity may exist in the EIM, either as an exact match, in which case it has the same meaning and scope as the entity in the EIM, or it may be encompassed by a "higher level" entity in the EIM. It is also possible, for a variety of reasons that a subsidiary model entity may encompass information that is represented in the EIM by more than one entity. This may arise where the focus of the subsidiary model is not upon the detailed management of the information concerned. Another important class of subsidiary model entities may be represented in the EIM as a relationship between two EIM entities. They are generated from the resolution of a many-to-many relationship on the EIM. Lastly, if the subsidiary model entity is so specific to a subject that it is regarded as unnecessary in the context of corporate data management, then it may not even be represented on the EIM, even though it may be related to entities that are on the EIM.

EIM conceptual entities do not include attributes or identify keys. Generally, attributes are specific to subsidiary model data entities. It is inappropriate to try to provide the full set of attributes and keys for entities at the level of the EIM, as in many cases the information concept cannot be so specifically defined.

How is the EIM related to the National Health Information Model?

The National Health Information Model (NHIM), published by the Australian Institute of Health and Welfare, was developed to provide a consistent framework for the health information utilised at a national level for monitoring health status and managing health care delivery. Much of this information is defined and described within the National Health Data Dictionary (NHDD). However, the links between the NHIM and the NHDD are loose as the model is at a high level of generalisation and the dictionary at a low level of specialisation and there is currently no intermediary model or NHDD model.

The NHDD is published with each data element grouped within the NHIM entities. The NHDD is developed and maintained by the National Health Data Committee (NHDC) and is available from the Australian Institute of Health and Welfare (AIHW) at http://www.aihw.gov.au/knowledgebase/index.html.

All data items in the NHIM have been cross-referenced to the appropriate DOH WA EIM entity (if the entity is included in the EIM). Where we believe equivalence exists between an EIM entity and an entry in the NHIM, then this assumption is referred to in the appropriate EIM dictionary entry. However, alignment between the two models is problematic as the NHIM focuses on reporting information requirements and the EIM stored information requirements.

Modelling and Documentation Standards

Entity Relationship Model (ERM)

The EIM uses entity relationship modelling to express the information concepts of interest to the DOH WA. This technique illustrates data only, not processes, and is a "snap shot" of the data at a point in time.

Entities

An entity represents a real world object, usually a person, place or thing that is of interest to the business and about which information is held. The following conventions are applied in the EIM:

Super-type/Sub-type Entities

An entity may be sub-divided into other entities; the original entity is then a super-type that contains sub-type entities. For example, CLIENT may be broken into INDIVIDUAL CLIENT and GROUP CLIENT. When a subtype is used the following conventions are applied:

Sub-types entities are represented as entity boxes drawn within the super-type entity box.

The sub-types of a super-type are mutually exclusive; for example, any instance of CLIENT is either an INDIVIDUAL CLIENT or a GROUP CLIENT, never both. Although a GROUP CLIENT may refer to an INDIVIDUAL CLIENT this rule would be represented by a relationship.

Each subtype of an entity may have things in common with all the other subtypes. These things in common (definition, attributes and relationships) will be inherited from the super-type entity. Each subtype will also have attributes that are unique to it.

Where the types of an entity do not have unique attributes that are of interest to Health they are expressed as a type entity. For example, an OTHER EVENT is classified by an OTHER EVENT TYPE, which would contain the code and description of the types of events.

Sub-typing within entities is expressed in the data dictionary as business rules. For example:

In the super-type entity CLIENT the business rule is expressed:

A CLIENT is either an INDIVIDUAL CLIENT or a GROUP CLIENT.

In the sub-subtype entity INDIVIDUAL CLIENT the business rule is expressed:

An INDIVIDUAL CLIENT is a type of CLIENT.

Relationships

Relationships illustrate the application of a business rule about the information that exists between entities.

For example:

A client is usually established in the Health system because of some type of health care event. Therefore, we can express this relationship between CLIENT and another entity HEALTH CARE EVENT thus:

A CLIENT is referred to in a HEALTH CARE EVENT.

Relationships are bi-directional and so there is also a rule that states:

A HEALTH CARE EVENT refers to a CLIENT.

We also illustrate that a client may have contact with the health system for more than one event. To express this we add cardinality to the relationship so that the rule becomes:

A CLIENT is referred to in one or more HEALTH CARE EVENTs.

It is also a rule that each event is only about a single client, so the cardinality is singular in the other direction and the rule becomes:

A HEALTH CARE EVENT refers to one CLIENT.

Multiple cardinality is illustrated by a convention called "crows-foot" notation, as it looks somewhat like the print of a birdís foot. If the cardinality is not multiple then the line remains simply a line. This notation is shown in the diagram below which illustrates the relationship line between CLIENT and HEALTH CARE EVENT.

The cardinality of relationships between entities can be one-to-one, one-to-many (as shown in the example) or many-to-many.

We also know that a client can enter the system before any health care event has taken place, but in order for there to be an event there must be a client. We illustrate this information by adding optionality constraints to the relationship. The business rules then become:

A CLIENT may be referred to in one or more HEALTH CARE EVENTs

A HEALTH CARE EVENT must refer to one and only one CLIENT

Optionality of "mandatory" is shown as a small line across the relationship line, while optionality of "optional" is indicated by a small circle, as shown in the diagram below.

Similarly to cardinality, the optionality of a relationship applies at each end. Thus a relationship can be optional at both ends, mandatory at both ends or mandatory at one end and optional at the other.

The cardinality and optionality of a relationship are dependent on the business rules of the organisation, since the business requirements drive the information model. For example, if the business rules of the organisation were to say that all clients are individuals (that is, there are no group clients) and health care can be delivered to a group then the relationship embodying these different business rule would be many-to-many rather than one-to-many. This new situation would be expressed in English as follows:

A CLIENT may be referred to in one or more HEALTH CARE EVENTs

A HEALTH CARE EVENT must refer to one or more CLIENTs

Recursive Relationships

Relationships may also be between an entity and itself. These are called recursive relationships. They may be one-to-many or many-to-many relationships, and are usually optional at one end.

A one-to-many recursion illustrates a hierarchy. So as not to limit the number of layers in the hierarchy it is shown as a relationship between an entity and itself. The relationship is mandatory at one end and optional at the other to reflect the nature of a hierarchy. This is often expressed using the metaphor of a tree, which has a hierarchy of trunk, branches and leaves. Thus a branch may have one or more leaves, but a leaf must belong to only one branch.

As an example, an organisation may be the parent company of another organisation. This is illustrated in an information model as a hierarchy where the ORGANISATION entity is related to itself in a recursive relationship as follows:

A many-to-many recursion illustrates another type of relationship called a product-component relationship due to its prevalence in the manufacturing industry where a product, such as an engine, can be made up of many components but can also be component used in many products, such as different models of cars. The optionality constraints illustrate that a component may be used in many products, but a product must have components.

Subject Areas and Business Areas

Information Modelling exercises often result in models that contain many entities. The DOH WA EIM contains approximately 300 entities. Presentation of large models is impractical, due to size limitations and the amount of crossovers that occur when drawing relationship lines making the model almost unreadable.

Examination of large models can often conclude that the entities cluster into related topics or subjects. Therefore it is practical to group all the entities to one cluster and create a smaller, more readable (and manageable) model whilst not losing the links to the entities in the other clusters. These clusters are called subject areas.

The DOH WA EIM has ten subject areas and each has been given an abbreviation. They are:

ACC

Accounts

ENV

Environmental Health and Licensing

HRS

Human Resources

LOC

Locations

PTY

Parties

RES

Physical Resources

PLN

Planning

POP

Population Health

RAB

Resourcing and Billing

SEV

Service Events

 

The lower-level DOH WA model has been broken up into four business areas and each has been given an abbreviation. They are:

CORE

Core Health

CORP

Corporate Services

INFO

Information Infrastructure

PLAN

Planning and Analysis

 

Relationship to DOH WA Information Subject Group Model

The Information Architecture Group within the DOH WA InfoHEALTH Alliance has created an information subject group model. This model is also based on the NSW Health EIM, but takes a system architectural approach rather than a classification of information entities, and contains subject groups that are subdivisions of the EIM subject areas.

The following table shows how each subject group relates to subject areas within the DOH WA EIM.

There are two subject groups that are not contained in Version 2.1 of the DOH WA EIM.

The "External Factors" group and the "Policies, Procedures & Standards" group represent architectural views of data rather than content, and will remain outside the DOH WA EIM.

All other subject groups either directly match EIM subject areas or are included within them.

Subject Group

Relationship

EIM Subject Area

Client ID & Demographics

Encompassed by

PARTIES

Health Event/Episode Details

Encompassed by

SERVICE EVENTS

Case Service Details

Encompassed by

SERVICE EVENTS

Client Care Plans

Encompassed by

SERVICE EVENTS

Public Health Subjects

Encompassed within

ENVIRONMENTAL HEATLH & LICENCING, POPULATION HEALTH

Service Events

Matches

SERVICE EVENTS

Service Results

Encompassed by

SERVICE EVENTS

Health Outcomes

Encompassed within

SERVICE EVENTS and POPULATION HEALTH

Community / Population Details

Encompassed within

SERVICE EVENTS and POPULATION HEALTH

Finance

Matches

ACCOUNTS

HR / IR

Matches

HUMAN RESOURCES

Physical Resource

Matches

PHYSICAL RESOURCES

Information Resources

Encompassed by

PHYSICAL RESOURCES

Supply Service

Encompassed by

ACCOUNTS and RESOURCING & BILLING

Third Parties

Matches

PARTIES

Service Providers

Encompassed by

HUMAN RESOURCES

Contracts & Agreements

Encompassed by

PLANNING

Business Management

Encompassed by

PLANING

Policies, Procedures & Standards

Not in EIM

 

Health Development / Promotion

Partial Match

POPULATION HEALTH

Service / Product Classifications

Encompassed by

SERVICE EVENTS

Geographic Locations

Matches

LOCATIONS

Document / Record Repository

Encompassed by

PHYSICAL RESOURCES

External Factors

Not in EIM