Standard Practice for Modeling in Health Informatics

SCOPE
1.1 Information models appropriately are used for analysis, design, and sharing a common understanding in health and healthcare information engineering, in healthcare process improvement, in building information systems, and in health informatics standards development.
1.2 The purpose of this practice is to identify best practices for the creation, use, and assessment of information models in the health and healthcare domain.
1.3 Included in this practice are recommended organizational policies and procedures, where modeling is best used in healthcare, and recommended modeling methods, best practices and evaluation criteria.
1.4 Excluded from this practice are detailed specifications of modeling techniques that are specified or described in other sources.

General Information

Status
Historical
Publication Date
09-May-2001
Current Stage
Ref Project

Relations

Buy Standard

Standard
ASTM E2145-01 - Standard Practice for Modeling in Health Informatics
English language
19 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


NOTICE: This standard has either been superseded and replaced by a new version or withdrawn.
Contact ASTM International (www.astm.org) for the latest information
An American National Standard
Designation: E 2145 – 01
Standard Practice for
Modeling in Health Informatics
This standard is issued under the fixed designation E 2145; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (e) indicates an editorial change since the last revision or reapproval.
1. Scope ISO 8601-88 Data Elements and Interchange Formats—
Representation of Dates and Times
1.1 Information models appropriately are used for analysis,
ISO/IEC 1087 Terminology Work—Vocabulary-Part 1:
design, and sharing a common understanding in health and
Theory and Application
healthcare information engineering, in healthcare process im-
ISO/IEC 11179 Information Technology—Specification
provement, in building information systems, and in health
and Standardization of Data Elements, Parts 1-6
informatics standards development.
ISO/IEC 2382 Information Processing Systems—
1.2 The purpose of this practice is to identify best practices
Vocabulary
for the creation, use, and assessment of information models in
2.4 FIPS Standards:
the health and healthcare domain.
Information Modeling (IDEF1X) Federal Information Pro-
1.3 Included in this practice are recommended organiza-
cessing Standard 184. Gaithersburg, MD: National Insti-
tional policies and procedures, where modeling is best used in
tute of Standards and Technology. December 21, 1993.
healthcare, and recommended modeling methods, best prac-
See also: IEEE 1320.2
tices and evaluation criteria.
Integration Definitions for Functional Modeling (IDEF0)
1.4 Excluded from this practice are detailed specifications
Federal Information Processing Standard 183. Gaithers-
of modeling techniques that are specified or described in other
burg, MD: National Institute of Standards and Technol-
sources.
ogy. December 21, 1993. See also: IEEE 1320.1
2. Referenced Documents
3. Terminology
2.1 ASTM Standards:
3.1 The following sections present terms, definitions, and
E 1239 Guide for Description of Reservation/Registration-
acronyms found in this practice and in various modeling
Admission, Discharge, Transfer (R-ADT) Systems for
activities.
Automated Patient Care Information Systems
3.2 Definitions:
E 1384 Guide for Content and Structure of the Electronic
2 3.2.1 activity, n—a group of logically related tasks per-
Health Record (EHR)
formed for a purpose.
E 1639 Guide for Functional Requirements of Clinical
2 3.2.2 alternate key attribute, n—any candidate key of an
Laboratory Information Management Systems
entity other than the primary key.
E 1715 Practice for Object-Oriented Model for Registra-
3.2.3 attribute, n—acharacteristicofanobjectorentity(see
tion,Admitting,DischargeandTransfer(RADT)Functions
ISO/IEC 11179).
in Computer-Based Patient Record Systems
3 3.2.4 attribute value, n—a representation of an instance of
2.2 ANSI Standards:
an attribute (see ISO/IEC 11179).
ANSI X3.172–1990 Dictionary for Information Systems
3.2.5 behavior column, n—a column is a physical data
IEEE 1320.1-1998 Standard for Functional Modeling
model and relational database structure that is analogous to the
Language—Syntax and Semantics for IDEF0
attribute of a logical data model.
IEEE 1320.2-1998 Standard for Functional Modeling
3.2.6 concept, n—a unit of thought constituted through
Language—Syntax and Semantics for IDEF1X (Object
abstraction on the basis of characteristics common to a set of
97)
objects, (see ISO/IEC 1087).
2.3 ISO Standards:
3.2.7 concept activity model, n—the activity component of
the Concept Model.
1 3.2.8 concept data model, n—the data component of the
This practice is under the jurisdiction of ASTM Committee E31 on Health
Informatics and is the direct responsibility of Subcommittee E31.25 on Healthcare Concept Model.
Management, Security, Confidentiality, and Privacy.
Current edition approved May 10, 2001. Published August 2001.
2 4
Annual Book of ASTM Standards, Vol 14.01. Available from National Technical Information Service (NTIS), U.S. Dept. of
Available from American National Standards Institute, 11 W. 42nd St., 13th Commerce, 5285 Port Royal Road, Springfield, VA 22161. http://
Floor, New York, NY 10036. http://www.ansi.org. www.fedworld.gov.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.
E2145–01
3.2.9 concept model, n—also known as a conceptual 3.2.27 logical data model, n—a data model that presents a
schema from the ANSI/X3/SPARC Study Group for Database logical organization of data in the form of entities, attributes
Management Systems. and relationships, especially where these components are
3.2.10 context, n—a designation or description of the appli- normalized.
cation environment or discipline in which a name is applied or 3.2.28 metadata, n—data that describes other data (see
from which it originates (see ISO/IEC 11179). ISO/IEC 11179).
3.2.11 data, n—a representation of facts, concepts, or in- 3.2.29 non-key attribute, n—an attribute that is not the
structions in a formalized manner, suitable for communication, primary or part of a composite primary key of an entity.
interpretation, or processing by humans or automatic means 3.2.30 object, n—any part of a conceivable or perceivable
(see ISO/IEC 11179).
world (see ISO 1087).
3.2.12 data dictionary, n—a database used for data that 3.2.31 object class, n—a set of objects, ideas, abstractions,
refers to the use and structure of other data; that is, a database
or things in the real world that can be identified with explicit
for the storage of metadata (see ANSI X3, 172-1990). boundaries and meaning and whose properties and behavior
3.2.13 data element, n—a unit of data for which the follow the same rules (see ISO/IEC 11179).
definition, identification, representation and permissible values 3.2.32 object-oriented methodology, n—any of several
are specified by means of a set of attributes (see ISO/IEC modeling and information management methods and tech-
11179). niques that employ objects rather than entities or tables.
3.2.14 data model, n—a description of the organization of 3.2.33 physical data model, n—a data model that presents
data in a manner that reflects an information structure (see
an organization of data in the form of tables, columns, and
ISO/IEC 11179). relationships.
3.2.15 data steward, n—a person or organization delegated 3.2.34 primary key attribute, n—the candidate key selected
the responsibility for managing a specific set of data resources, as the unique identifier of an entity.
(see ISO/IEC 11179). 3.2.35 property, n—apeculiaritycommontoallmembersof
3.2.16 dependent entity, n—an entity that inherits one or an object class (see ISO/IEC 11179).
more identifying attributes from another entity. 3.2.36 relational data methodology, n—anyofseveralmod-
3.2.17 domain, n—the set of possible data values of an eling and information management methods and techniques
attribute (see ISO/IEC 2382). that employ structured relationships among entities or tables.
3.2.18 entity, n—any concrete or abstract thin of interest, 3.2.37 row, n—a row is a physical data model and relational
including associations among things (see ISO/IEC 2382). databasestructurethatcontainsaninstanceofdatainacolumn.
3.2.38 subject area, n—a subject area is a portion of an
3.2.19 external schema, n—an external schema is the rep-
resentation of data at the system architecture presentation layer entiredatamodelwhichiscreatedtofacilitateunderstandingof
a specific functional area or component task.
as viewed by the user when interacting or communicating with
the information system. 3.2.39 table, n—a physical data model and relational data-
3.2.20 foreign key attribute, n—an attribute or combination base structure that is analogous to the entity of a data model.
of attributes of a child or category entity whose values match 3.2.40 transformational data model, n—a data model that is
those in a primary key of a related or generic entity instance. optimized for performance on a specific technology.
3.2.21 function, n—an activity, process or transformation 3.2.41 view (such as clinical), n—a collection of entities
identified by a verb that describes what would be accom- and assigned attributes (domain) assigned for some purpose.
plished. 3.3 Acronyms:
3.2.22 independent entity, n—an entity that does not inherit 3.3.1 ANSI—American National Standards Institute.
identifying attributes from another entity. 3.3.2 ASTM—American Society for Testing and Materials.
3.2.23 internal schema, n—a schema of the ANSI X3/ 3.3.3 CODASYL—Conference on Data Systems and Lan-
SPARC Three Schema architecture in which views of the
guages.
information are representations of data structure at the system 3.3.4 ICOM—Input, Control, Output and Mechanisms of
architecture data layer.
IDEF activity modeling.
3.2.24 key attribute, n—an attribute used to identify an
3.3.5 ICT—Information and Communications Technology.
instance of an entity. 3.3.6 IDEF—Integrated Definition Language.
3.2.25 key inheritance, n—the transmission of a key at- 3.3.7 IDEF0—The IDEF activity modeling language.
tribute from a parent or independent entity to a child or
3.3.8 IDEF1X—The IDEF data modeling language.
dependent entity.
3.3.9 IDO—Integrated Delivery Organization.
3.2.26 lexical, n—pertaining to words or the vocabulary of
3.3.10 IE—Information Engineering diagramming method-
a language as distinguished from its grammar and construction
ologies.
(see ISO/IEC 11179).
3.3.11 IEC—International Electrotechnical Commission.
3.3.12 ISO—InternationalOrganizationforStandardization.
3.3.13 ISA—Information Systems Architecture.
3.3.14 UML—Unified Modeling Language.
ANSI Standards Planning and Requirements Committee-a layered model of
3.3.15 DFD—Data Flow Diagram.
database architecture comprising a physical schema, a conceptual schema, and user
views. 3.3.16 SML—Standardized Modeling Language.
E2145–01
3.3.17 NIST—National Institute of Standards and Technol- 4.4.3 The Zachman Information SystemsArchitecture (3) is
ogy. an effective tool to describe the totality of an organization from
3.3.18 SQL—Structured Query Language. an informatics viewpoint. The Zachman ISA, therefore, is a
3.3.19 CRC—Class, Responsibility and Collaboration Ap- suitable framework for identifying models that represent the
proach. informatics structure and processes of the organization.
3.3.20 RDB—Relational Database. 4.5 Conceptual Correctness:
3.3.21 RDBMS—Relational Database Management System.
4.5.1 All models are representations of real objects or
3.3.22 CORBA—CommonObjectRequestBrokerArchitec- concepts.
ture.
4.5.2 The model must accurately describe the intended real
organizational structures or processes, or both, and effectively
4. Summary of Practice communicate this description to anyone who understands the
modeling method and syntax.
4.1 This practice describes policies and procedures, best
4.6 Conceptual Completeness:
practices for the creation, use, and assessment of health
4.6.1 Models describe the full scope or an element of the
information models, and typical applications of information
structures or processes, or both, of an organization or concept.
modeling in the health and healthcare domain.
4.6.2 The model must contain sufficient objects to describe
4.2 The foundation for best practices in health information
the full scope of the intended health or business domain.
modeling may be derived from structure, process and outcome
4.7 Syntactic Correctness:
quality constructs (1).
4.2.1 Quality Construct—Information Modeling Area Sup- 4.7.1 Each modeling method has a predefined language
typically consisting of visual structures and symbols. Rules
ported.
4.2.2 Structure: govern the manner in which these structures and symbols are
assembled and interpreted.
4.2.2.1 The organization component where modeling activi-
ties occur. 4.7.2 The modeling method must use a recognized and
4.2.2.2 The composition of the modeling method or tool, its preferably standardized set of rules (4).
language and syntax.
4.7.3 The model must adhere to the syntax of the modeling
4.2.3 Process: methodology.
4.2.3.1 Appropriate use of modeling.
4.8 Syntactic Completeness:
4.2.3.2 Effective use of modeling methods.
4.8.1 A modeling method may use different objects, sym-
4.2.3.3 Correct employment of the modeling technique.
bols or structures at different times in the modeling process.
4.2.4 Outcome—A quality health informatics model that
4.8.2 Themodelmustemploytheappropriatestructuresand
provides a meaningful representation of past, present, or future
symbols at the appropriate place in the model and at the
reality.
appropriate time in the modeling process.
4.3 The five dimensions (2) of model quality that derive
4.9 Additional Technical Considerations:
from these quality constructs are as follows:
4.9.1 In addition to the dimensions of quality, several
4.3.1 Conceptual Correctness—The model accurately re-
technical considerations impact the quality of an informatics
flects health or business concepts.
model (4).
4.3.2 Conceptual Completeness—The model contains suffi-
4.9.1.1 Nonredundancy—Afact must be represented at only
cient objects to describe the full scope of the target health or
one point in the model.
business domain.
4.9.1.2 Business Rules Enforcement—The model accurately
4.3.3 Syntactic Correctness—The objects in the model do
reflects organizational, health, or business processes.
not violate syntactic rules of the modeling language.
4.9.1.3 Reuseability—The content of the model is acces-
4.3.4 Syntactic Completeness—All health or business con-
sible to other than the originally intended users.
cepts are captured at appropriate points in the modeling
4.9.1.4 Stability—The model accepts changing health or
process.
business requirements without significant alteration in the
4.3.5 Enterprise Awareness—The model depicts the entire
structure of the model.
enterprise or can be seamlessly integrated with other models
4.9.1.5 Flexibility—The model is capable of supporting
across the entire organization.
change in health concepts or business processes.
4.4 Enterprise Awareness:
4.9.1.6 Simplicity—The model is easily understandable and
4.4.1 The foundation of a quality information model is the
well presented.
ability to describe the entire organization, either by itself or
4.9.1.7 Implementable—The model may be readily and
when combined with other comparable models.
economically used in analysis, design, development, or opera-
4.4.2 Multiple models must seamlessly integrate across the
tion.
entire organization and their descriptions must rationally
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.