1 Introduction
The purpose of this document is to provide direction on the implementation of the elements of the Corporate Meta Data Lifecycle, shown in Figure 1. After development, the corporate meta data will enter a cycle of Distribution, Utilisation, Feedback and Change. The use of standards and the availability of support for both the software environment and the model will underpin this lifecycle.
Corporate Meta Data refers to the Enterprise Information Model (EIM), the Business Area Information Models (BAIM) that are the next level of specialisation in the model hierarchy, and the WA Health Corporate Data Dictionary (WAHCDD).
Development, distribution and change of Corporate Meta Data will be managed centrally by the Consultant Corporate Meta Data located within the Health Information Centre's (HIC) and overseen by the Corporate Metadata Advisory Group (CMAG). Utilisation of the EIM will be distributed throughout the organisation and mandated by policy in some instances such as information systems planning, development and package selection. Feedback channels will be in place for all types of users from all areas of utilisation both internally and externally to the Western Australian Department of Health (WA DOH).
2 Background
2.1 Policy
A Data Management Policy (P07/0995) is in place for the DOH, which seeks to "utilise common definitions and usage of data to ensure that meaningful information can be provided by information systems of strategic or operational significance in the most consistent and cost effective manner. " However, in the recent past the implementation of this policy has been limited due to a lack of underlying procedures.The development and implementation of the Corporate Meta Data, in the form of the EIM, BAIM and the WAHCDD, will establish an environment in which this policy can be comprehensively applied. Corporate Meta Data management will include the development and implementation of procedures for all aspects of the Corporate Meta Data lifecycle, thus establishing a mechanism for putting the policy into action.
Accordingly the updated Data Management Policy incorporates the EIM into the characteristics of data management and states that "the DOH EIM is the implementation mechanism for Data Management within the government health sector."
3 Development
3.1 Corporate Meta Data
In the first instance Corporate Meta Data will be derived both top down, from business requirements, and bottom up, from existing application systems meta data. Once established, Corporate Meta Data will be the primary definitional source for health information. That is, meta data should first be defined at a corporate level and those definitions used as the basis for development of data definitions within application systems, both operational systems and those for the provision of management information, throughout the DOH.
3.2 National Meta Data
While National meta data must be taken into account when developing both corporate and applications’ meta data, it should not drive data definition at this time. National meta data, as defined in the National Health Data Dictionary (NHDD), focuses on national reporting requirements whereas the focus of the EIM and lower level applications data models is on stored information requirements to meet the business requirements of DOH. However, the current requirements for provision of data as specified in National Minimum Data Sets (NMDS) and other mandatory reporting requirements must continue to be met and should be derivable from the data held within DOH applications.
3.3 Applications Meta Data
Applications’ meta data will be developed and maintained at both the logical and physical level. Each application’s Logical Data Model (LDM) will be derived from the Corporate Meta Data (refer to section on Utilisation below) and then implemented as physical meta data.
Applications’ meta data will include definitional requirements for data views and extracted data used for analytical and reporting purposes. In fact, wherever data is available, meta data should also be available in the same medium. For example, data that can be browsed and manipulated by web applications should be accompanied by web enabled meta data.
4 Utilisation
Beta versions of the Corporate Meta Data will have restricted distribution to within the DOH; therefore, utilisation will initially be internal only. This will broaden to external users when the Corporate Meta Data is approved for publication on the Internet.
Procedures for utilisation will differ, particularly within the DOH, as different users will have different requirements. Where utilisation is mandated by policy, an exception report and or reconciliation with the Corporate Meta Data, or an approved exception, will be required. Exception reporting and reconciliation documents will be at different levels of detail depending on the nature of the activity.
Assistance in producing these required documents will be provided by the Consultant Corporate Meta Data within the Health Information Centre.
4.1 Mandatory Utilisation
4.1.1 Information and Information Systems Planning
All information and information systems planning activities, whether sponsored by individual Divisions, Health Services, the Department or InfoHEALTH Alliance, should align with the Enterprise Architecture and the Corporate Meta Data. This ensures that expenditure on information resources best supports the enterprise business requirements and standards as specified in these overarching documents.
These activities will include:
- Strategic planning for information and data management;
- Tactical or operational planning that covers:
- implementation of new information systems,
- modification of existing systems,
- integration of existing systems,
- specification of new Minimum Obligatory Information Requirements (MOIR), or
- specification or consideration of new NMDS.
Planning activities should reference the Enterprise Architecture and the EIM to establish the degree of fit between these documents and existing systems and data collections, any planned changes or developments.
It is essential that any Business Case arising from the planning activities and submitted for funding approval using the Business Case Guidelines for Information Systems (G13/0499) includes in Section 3.3 Relationship to Priorities and Goals reference to the system’s fit to the Enterprise Architecture and the Enterprise Information Model.
4.1.2 System Integration or Interface
Common data definition is specified in the Corporate Meta Data, one purpose of which is to facilitate integration of information systems. Therefore, all data that is used by more than one application (information system) within the health system domain must utilise these common definitions. Migration planning should be undertaken to ensure that, over time, applications comply with common definitions.
The level of specialisation of the data definitions within the data dictionary will be greater where data is shared. Where data is not shared it will be maintained at a more generic level in the generalisation/specialisation hierarchy, thereby allowing some system-specific flexibility.
Where system interfaces are established and data cleansing, translation or mapping takes place, the common data definitions should be utilised in producing the target data.
4.1.3 System Analysis, Design and Development
Analysis and design of new applications data requirements will begin with the Corporate Meta Data. The meta data will be refined through a process of further specialisation to meet the needs of the application so that the Corporate Meta Data and the application’s logical meta data have a generalisation/specialisation hierarchy between them. Where the detailed application specific data modelling process identifies issues with the more generic meta data, developers and the Consultant Corporate Meta Data will work together to establish where and if changes are required. This process will produce an exception report where reconciliation cannot occur.
System development activities such as database construction should not commence until reconciliation with Corporate Meta Data has been completed and approval to proceed obtained from the Enterprise Information Model Advisory Group.
For the purposes of this document Data Warehouses and Data Marts are considered system developments and must, therefore, utilise the Corporate Meta Data in the definition of data and information. Reconciliation methods may differ, as the modelling protocol used may not be on a strict entity-relationship basis.
4.1.4 Information Systems Maintenance
All information systems must have a logical data model that is maintained and kept aligned to the Corporate Meta Data. Where systems are in place that do not have a logical data model a cross-reference between the physical database and the Corporate Meta Data should be maintained.
Where system changes result in definitional inconsistencies these should be documented in an exception report and submitted to Consultant Corporate Meta Data.
Systems maintenance activities that impact physical and/or logical meta data should not be approved through the system's change management process until reconciliation with Corporate Meta Data has been completed and approval to proceed obtained from the Enterprise Information Model Advisory Group. In other words, the meta data change management process should be embedded in every system's change management process.
4.1.5 Package Selection
In order to assess package solutions to information systems requirements, an understanding of the data requirements is essential. Corporate Meta Data should be used for this purpose.
Corporate Meta Data should be included in the requirements document submitted to vendors for supply; this could take the form of a pointer to the Internet address. Adherence to the lowest level of specialisation of Corporate Meta Data available for the subset of health data to which the system pertains must be a selection criterion for the package evaluation.
Where an application specific conceptual model is produced it should be derived from the subject area model in the same manner as for custom developed systems. Where the conceptual data modelling process identifies issues with the more generic meta data, the modeller(s) and the Consultant Corporate Meta Data will work together to establish where and if changes are required. This process will produce an exception report where reconciliation cannot occur. Once approved, the application level conceptual model must be included in the requirements document and package solutions evaluated against it.
It is not anticipated that any package solution will have a 100% match to the meta data provided. Therefore, short listed package solutions must be evaluated against the meta data requirement and an exception report produced as described in section 9.3 EIM Reconciliation Procedure. For package selection, this should include estimates of the cost of managing the mismatches encountered, as this will have low or no impact where data is unique to the package, but could be quite high where data is shared and translations are required.
4.1.6 Package Implementation
Package vendors often do not supply a logical data model with the package software as it is considered to be proprietary. Where this is the case, a meta data cross-reference should be maintained so that any accepted definitional inconsistencies between system and Corporate Meta Data are known and documented.
Any customisation of the software will require the same change management process, in respect to meta data, as for custom developed systems. Customisation that impacts physical and/or logical meta data should not be approved through the change management process until reconciliation with Corporate Meta Data has been completed and approval to proceed obtained from the Enterprise Information Model Advisory Group.
Software upgrades, implementation of new releases or fixes that change database structures should be followed by a review of the reconciliation to Corporate Meta Data.
4.1.7 Data Collection
Requests for data collections, whether one-off or ongoing, should only be for information within the health domain and, therefore, maintained in the Corporate Meta Data. Requests for data that are defined in existing meta data must be consistent with those definitions. Requests for data collections that are outside the domain covered by the Corporate Meta Data should be considered as a change to business requirements and, as such, must trigger the change management process for the Corporate Meta Data.
Where data collection requests come from National or State authorities external to the DOH, to whom the DOH has obligatory reporting arrangements or reporting agreements, every effort should be made to ensure that these requests are consistent with available data and as defined in existing meta data. Data collections that include data that is not currently available should be consistent with Corporate Meta Data. Staff representing the State on committees and working groups that are developing specifications for new data collections must utilise the Corporate Meta Data and keep the EIM Advisory Group informed of data definitional outcomes.
4.2 Optional Utilisation
4.2.1 Data Analysis and Reporting
Corporate Meta Data should assist those who utilise Health Data for analysis and reporting, such as epidemiologists, health care planners and purchasers. Meta data provides definitions of the meaning of data that is being analysed or from which reports are derived. Corporate Meta Data will make available common enterprise wide definitions that can be utilised when using data from multiple sources or when identifying where, or whether, appropriate data for the purpose is available.
4.2.2 Other
Some or all of the WA Health Corporate Meta Data will be generally available for query access to people both internally and externally to the health system. As this information will be in the public domain no restrictions, other than those of copyright, can be placed on its utilisation.
5 Distribution
5.1 Medium
The primary means of distributing the EIM, its associated submodels and data dictionary will be via the Department of Health Intranet.
Printed versions will only be distributed to people or organisations specifically making such a request in writing. Printed versions will only be maintained if specifically requested. New printed versions will be distributed only for major releases.
5.2 Versions
Published material must be labelled with a version number as defined by section 10.1 EIM Publication Version Numbering Standard.
5.3 Publication Triggers
Publication of a new version of the EIM will be planned and tracked as a project controlled by (and normally executed by) Corporate Meta-Data Management staff.
The Intranet will always contain the latest version of the EIM. Printed versions will only be published for major releases or on specific request.5.4 Publication Process
When a new version of any document within the EIM is to be published, the process will be carried out in accordance with the EIM Publication Procedure, which addresses all aspects of publication, including
- The units of publication
- Document naming and version control standards
- How new publications are to be tested before final publication
- Authorisation and approval of new publications
- The methods to be used to physically publish documents
- How obsolete documents are to be archived
6 Feedback
To encourage the active participation of as many people as possible, one or more mechanisms must be put into place to allow feedback.
All feedback will in the first instance be directed towards the custodian of the EIM, the Consultant Corporate Meta Data within the HIC. The primary mechanism to be introduced will be pre-addressed e-mail on the Intranet. Secondary mechanisms will be ad-hoc e-mail, conventional mail and telephone calls. Telephone calls must be logged.
The utilisation of feedback will need to be governed by one or more procedures. These procedures at a minimum should include the following:
Feedback will need to be categorised to allow appropriate action to be taken. Categories to be used should include as a minimum:
- Change requests
- Comments
- Requests for assistance
The custodian of the EIM has responsibility for categorising feedback and carrying out any action, tracking and resolution of issues raised as a result.
All feedback should be filed into a consolidated feedback folder and an entry made into a Feedback Register as defined in the EIM Feedback Tracking Standard.
All feedback from the Intranet or conventional mail should be acknowledged, usually via e-mail but possibly via conventional mail. Feedback from the public web site should be acknowledged at the discretion of Consultant Corporate Meta Data.
6.1 Action Paths
6.1.1 Change Requests
Change requests must be directed into the Change Control procedure. A copy of the feedback should be made into the supporting documentation for the Change Request generated.
6.1.2 Requests for Assistance
If the assistance is to exceed one telephone call, a copy of the feedback should be made into the supporting documentation for the Work Request generated.
Problem Reports
Depending on the nature of the problem reported, this may be copied to the Help Desk or generate a Work Request.
Comments
The Consultant Corporate Meta Data should file feedback comments in printed form in a standard file. Some comments could be the cause of raising an issue. In that case, following the Issue Management procedure would make a copy of the feedback.
7 Change
7.1 Overview
Changes to Corporate Meta Data may arise either from changes to information systems or from changes to processes or business requirements. Corporate Meta Data includes descriptions of information that may not be managed by computer systems.
To derive most benefit from Corporate Meta Data, it must be kept in alignment with the physical reality of the business processes and requirements of the DOH. To this end, a standard approach should be adopted to integrating maintenance of Corporate Meta Data into the management of all changes to the DOH business environment. This may be achieved by including consideration of changes to meta data in change management procedures.
7.2 Change Management and Change Control
Change management is concerned with the general management concerns of resourcing, budgeting and planning as applied to making changes to an existing environment. This process is addressed within the DOH by its Change Management Standard (S01/1295).
Any change made to systems or processes within the DOH that potentially affects the definition of Corporate Meta Data should include such considerations as part of the change management approval process. If meta data changes are identified, the process must involve the Consultant Corporate Meta Data.
Change Control is concerned with tracking changes made to a stable environment. For the DOH EIM, this process is described by section 9.1 EIM Change Control Procedure and its associated standards.
7.3 System Changes
As a general principle, definitional changes should first be made to logical meta data and validated against corporate meta data before being applied to physical meta data (i.e., database definitions). This principle is to apply to all custom developed systems and wherever possible to package solutions.
It will be possible for changes that are identified at applications level to alter the corporate meta data, but only where this reflects the business requirements for the whole of health.
8 Support
8.1 Infrastructure Support
The EIM and its components will be implemented using various software products, including:
- The CASE tool and its repository
- The word processing product used for general document preparation
- The web page generation product used to create web page forms of the published
- The diagramming tool used to generate Entity Relationship diagrams for publication
- Possibly a version control system
- The Department of Health Help Desk will support the tools applicable to desktop machines. The CASE tool may need to be allocated server support through the InfoHEALTH Alliance, although day to day administration should be allocated to the Consultant Corporate Meta Data (who may delegate).
8.2 Data Architecture Support
The Consultant Corporate Meta Data will provide support for the contents of the EIM and its components.
This support will take the following forms:
- Registration and actioning of change requests for the EIM
- Assistance in use of the EIM - this may be responding to one-off inquiries or formal participation in application system design
- Delivery of tutorials on the EIM and its use
- Distribution of EIM publications, both printed and online
- Maintaining alignment between the DOH EIM and National models and requirements
- Maintaining public awareness of the existence and importance of Corporate Meta Data. This can be achieved by publishing informational bulletins covering topics such as:
- Changes to National models or requirements
- Planned activities related to the EIM and its maintenance (eg participation in new system design or acquisition, forthcoming releases)
- Other items of information related to documentation of Health information structures elsewhere in Australia or internationally
9 Procedures
9.1 EIM Change Control Procedure
The EIM and its components are under Change Control as defined by this procedure.
9.1.1 Scope
All documents produced for publication as part of the EIM, including the high-level model, all submodels, the data dictionary(ies), cross-references to other systems or requirements (such as the NHIM, NHDD, NMDS and any MOIR requirements) and any explanatory or descriptive documents.
The repository used by the selected CASE product.
9.1.2 Version Identification
Documented standards must be followed for identifying versions. Section 10.1 EIM Publication Version Numbering Standard defines the standard for published documents. Section 10.2 EIM CASE Repository Version Identification Standard defines the standard for the CASE repository.
9.1.3 Version Tracking
Each version created of either a published document or the CASE Repository shall have an entry in the DOH EIM Version Register documenting as a minimum:
- The type of object being versioned (i.e., document or repository)
- The name of the file or directory
- The version identifier
- The date allocated
- The person creating the version
- The person authorising the creation of the version and when authorised
- The person approving the version to be published and when approved
- The reason for creating the version
- A brief description of the contents of the versioned object
- The status of the newly created version to be set to "testing"
- When the new version of the object is published, the status of the version record is set to "active" and if there is a previous version that this replaces, the status of the older version is set to "obsolete"
- A published document is to state which version of the CASE repository it is linked to
- The identifier of any Work Request(s) fully or partly implemented by this version
9.1.4 Authorisation and Approval
Both CASE repository versions and publication versions must be authorised and approved. The EIM Version Register indicates who authorised a version and when, and who approved a version for publication and when.
9.2 EIM Publication Procedure
This procedure covers all aspects of publishing a version of the EIM.
9.2.1 Overview
When a decision has been made to produce a new version of a document forming part of the DOH EIM, an entry is made in the DOH EIM Version Register for the document as specified in the EIM Change Control Procedure.
The new version of the document is named according to the entry in the Version Register, generated, tested, approved for publication and finally published.
Versions of documents that are not current must be archived.
9.2.2 Publication Units
The EIM incorporates several components, including:
- A high-level Corporate Entity Model made up of subject area specific Entity Relationship Models
- A series of more detailed Business Area Information Models (BAIM)
- A Western Australian Health Corporate Data Dictionary (WAHCDD)
- A series of documents indicating cross-references between the DOH EIM and national or other external models or requirements (eg NHDD, NHIM, NMDS, other MOIR requirements)
- Explanatory or descriptive documents
Each of these documents may be published separately. It is the responsibility of the Consultant Corporate Meta Data to ensure that linked documents are published together.
9.2.3 Naming Standards
Documents that are published as part of the DOH EIM will be named according to section 10.5 EIM Publication Document Naming Standard.
9.2.4 Version Control
As defined in section 9.1 EIM Change Control Procedure, versions of documents are recorded in the DOH EIM Version Register, and this record refers to which version of the CASE repository the document version relates.
9.2.5 Testing
Testing is normally only required for publications to the Intranet or Internet public web site. The proposed version of the document must be transferred to a test web server using standard Department of Health procedures for doing so. All web pages must be tested according to section 10.6 EIM Web Publication Testing Standard.
9.2.6 Authorisation and Approval
Creation of a version of a document is authorised and approved as defined in section 9.1 EIM Change Control Procedure. The approval as recorded in the DOH EIM Version Register is approval to publish the version of the document specified. Approval should only be given after the publication has been tested.
9.2.7 Publication
Publication of a document is always carried out by making a copy of the "master" file which is being published. Master files are stored in a directory structure established on a file server according to section 10.5 EIM Publication Document Naming Standard. Update access to this directory structure is limited to authorised staff members of the Health Information Planning Unit.
For publication to the Intranet, the copy is the file which has been used for testing. This file is published by moving it to the appropriate location on the appropriate production web server as defined by Department of Health Intranet Support procedures. The previous version of the file (if it exists) is deleted from that web server and the master version of it is archived.
9.2.8 Archiving
A document that is not a current version is by definition obsolete. Obsolete documents must be archived according to 10.7 EIM Publication Archiving Standard.
9.3 EIM Reconciliation Procedure
9.3.1 Overview
To maintain the EIM’s alignment with the business requirements and data environment of the DOH, any changes to either the business or operational environment must involve an assessment of whether that alignment has been disturbed. If so, the extent of misalignment is to be documented and used to generate a reconciliation document describing how the alignment is to be restored. Where action is required, this will be triggered and tracked through existing work management procedures and processes by raising work requests.
9.3.2 Inputs
The primary input will be some form of notification to the Consultant Corporate Meta Data of the change that requires meta data review. The form of this notification may vary depending upon the nature of the change. Types of change addressed in the EIM Management Guidelines include:
- Information-related business changes including changes to National models such as the NHDD, NHIM, NMDS or other MOIR information.
- Introduction of new information systems, either to be developed internally or implemented as a package.
- Changes to existing information systems, either internally developed or packages.
In general, notification of changes to information systems will be generated as part of change management procedures within the DOH, while notification of changes resulting from external organisations will be less formal.
9.3.3 Outputs
The process of reconciling an information change in the DOH environment with the EIM will generate up to four documents and possibly one or more change requests.
The documents that may be generated are:
- LDM-EIM Exception Report: Contains documentation detailing any aspects of the Logical Data Model of a system and the EIM and its components that do not match.
- LDM-EIM Reconciliation Report: Contains documentation detailing how exceptions on an LDM-EIM Exception Report will be reconciled with the EIM (whether changes will be made to the EIM, the system, changes simply noted or some other means)
- Package-EIM Meta Data Cross-Reference: A tabular listing of data entities and attributes identified within a package cross-referenced to equivalents within the EIM and its components.
- Physical-EIM Cross-Reference: A tabular listing of tables and columns within a system’s database cross-reference to EIM meta data.
These documents will be filed with the Coonsultant Corporate Meta Data and copies may be used to support change requests generated to implement system changes required to achieve alignment between the EIM and the DOH information environment.
9.3.4 Records Kept
Each reconciliation will potentially generate the following records and documents that will be filed:
- Initial notification of change requiring reconciliation with the EIM
- LDM-EIM Exception Report
- Reconciliation Report
- Package EIM-Meta Data Cross-Reference
- Physical-EIM Cross-Reference
- Copies of Work Requests generated
- Statement of which components and versions of the EIM first satisfy the reconciliation
10 Standards
10.1 EIM Publication Version Numbering Standard
All material distributed will contain a version number.
For distribution purposes, there will be two levels of versioning. In descending order of importance, these will be:
- Release
- Version
Both these will be numeric. The following list gives an example of a pattern of versions published successively:
- Release 1, version 0 (major)
- Release 1, version 1 (minor)
- Release 1, version 2 (minor)
- Release 2, version 0 (major)
- Release 2, version 1 (minor)
Standard documents will contain a footer on each page containing the version number, and a version control page following the title page.
10.2 EIM CASE Repository Version Identification Standard
Each version of the repository used by the CASE tool to contain the meta data definitions of the EIM (including subject areas, applications, entities, relationships, attributes, data definitions and ER diagrams) must be uniquely identified.
The precise method of achieving this is dependent upon the CASE tool in use.
10.3 EIM Feedback Tracking Standard
Each item of feedback will be logged into the EIM Feedback Register.
The Feedback Register will indicate the date and source of the feedback and its most recent status (logged, action commenced, completed).
10.4 EIM Distribution Tracking Standard
The Consultant Corporate Meta Data will maintain a Distribution Register. For each person or organisation receiving a printed version of the EIM, the register will contain the contact details for the person, and the EIM Document name including version number for each document distributed to that person or organisation.
10.5 EIM Publication Document Naming Standard
This standard defines how master directory structures are named and how published documents are to be named.
The master directory for publication documents is to be established on a file server with read-only permissions for everyone, and update permissions only for the Consultant Corporate Meta Data. It is to be called "DOH EIM". Three subdirectories within DOH EIM are to be established named "Current", "InProgress" and "Archived". Another directory is to be established named "Version Register".
A document name is to be composed of a generic component, a version component and a file suffix. The version component is the version identifier as defined in the EIM Publication Version Numbering Standard prefixed with the letter "V". The generic component of the name simply has to be a valid file-name. The suffix is used to indicate the type of document and will be associated with a specific software product (normally ".doc", associated with Microsoft Word).
Example:
DOH EIM Agreements Subject Area Data Model V1.2.doc
10.6 EIM Web Publication Testing Standard
All links on web pages must be specified as relative to the current page, and all links must be tested. All embedded script code and all invoked software (eg Java applets) must also be tested. All graphics must be tested. All web pages must conform to Department of Health Intranet standards and follow Department of Health Intranet guidelines as closely as possible.
10.7 EIM Publication Archiving Standard
Any published document that becomes obsolete must be archived. The archival process commences with updating the document version’s entry in the DOH EIM Version Register to make the status "obsolete". The master version of the file must then be moved to the standard archive directory structure (contained within the overall master directory structure).
11 GLOSSARY
|
TERM |
DEFINITION |
|
Enterprise Architecture |
The Enterprise Architecture is a specification of the most effective and efficient way for major component systems to support the business of the enterprise. It takes into consideration the work to be done, the applications required to support that work, the information that is required and used, and the technology deployed to deliver that information. The information component of the Enterprise Architecture should always be a subset of the Enterprise Information Model, presenting a view of information suited to the operational requirements of information systems. |
|
Enterprise Information Model |
A picture, using a specific diagramming technique (eg, Entity Relationship Modelling), which represents the various types of information that are required within the domain being modelled (i.e., the DOH). |
|
Corporate Meta Data |
In general corporate meta data is any meta data that is defined centrally for the organisation as a whole. For the purposes of this document, Corporate Meta Data refers to the hierarchy of EIM meta data, that is, the highest level of generalisation documented called the EIM, all subsidiary subject area models maintained centrally, and the WAHCDD |
|
NHDD |
National Health Data Dictionary |
|
NHIM |
National Health Information Model |
|
NMDS |
National Minimum Data Set |
|
MOIR |
Minimum Obligatory Information Requirements |
|
WAHCDD |
Western Australian Health Corporate Data Dictionary |
|
DOH |
Department of Health |
|
EIM |
Enterprise Information Model |