1、Designation: E 1715 01 (Reapproved 2008)An American National StandardStandard Practice forAn Object-Oriented Model for Registration, Admitting,Discharge, and Transfer (RADT) Functions in Computer-Based Patient Record Systems1This standard is issued under the fixed designation E 1715; the number imme
2、diately following the designation indicates the year oforiginal adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. Asuperscript epsilon () indicates an editorial change since the last revision or reapproval.1. Scope1.1 This
3、 practice is intended to amplify Practice E 1239 andto complement Practice E 1384 by detailing the objects thatmake up the reservation, registration, admitting, discharge, andtransfer (RADT) functional domain of the computer-basedrecord of care (CPR). As identified in Practice E 1239, thisdomain is
4、seminal to all patient record and ancillary systemfunctions, including messaging functions used in telecommu-nications. For example, it is applicable to clinical laboratoryinformation management systems, pharmacy information man-agement systems, and radiology, or other image management,information m
5、anagement systems. The object model terminol-ogy is used to be compatible with other national and interna-tional standards for healthcare data and information systemsengineering or telecommunications standards applied to health-care data or systems. This practice is intended for thosefamiliar with m
6、odeling concepts, system design, and imple-mentation. It is not intended for the general computer user or asan initial introduction to the concepts.2. Referenced Documents2.1 ASTM Standards:2E 1238 Specification for Transferring Clinical ObservationsBetween Independent Computer Systems3E 1239 Practi
7、ce for Description of Reservation/Registration-Admission, Discharge, Transfer (R-ADT)Systems for Electronic Health Record (EHR) SystemsE 1384 Practice for Content and Structure of the ElectronicHealth Record (EHR)E 1633 Specification for Coded Values Used in the Elec-tronic Health RecordE 1639 Guide
8、 for Functional Requirements of ClinicalLaboratory Information Management Systems3E 1744 Practice for View of Emergency Medical Care in theElectronic Health RecordF 1629 Guide for Establishing Operating Emergency Medi-cal Services and Management Information Systems, orBoth2.2 ANSI Standard:ANSI X3.1
9、72 Dictionary of Information Systems42.3 IEEE Standard:IEEE 1157.1 Trial Use Standard for Healthcare InformationInterchangeInformation Modelling (6 June 1994)52.4 Other Document:HL-7 v2.4 Data Communication Standard63. Terminology3.1 DefinitionsGeneral terms are defined in accordancewith ANSI X3.172
10、.3.2 Definitions of Terms Specific to This Standard:3.2.1 functional domain, nthat area of activity that en-compasses a given function. (HL-7, v2.4)3.2.2 healthcare domain, nthat functional domain encom-passing all aspects of the delivery of health care, both preven-tive and corrective, to patients,
11、 and the management ofresources enabling that care to be delivered. (HL-7, v2.4)4. Background4.1 Object Representation of RADT ProcessesPracticeE 1239 provides the experiential background of the functionsin RADT. These functions are common to all systems that dealwith patient data. The minimal essen
12、tial data elements forRADT were identified and characterized partly in PracticeE 1239. Table 1 of that guide identifies a logical data structurefor the data elements, but it does not relate these elements toconstituent “entities” or “objects” in the sense that they are1This practice is under the jur
13、isdiction of ASTM Committee E31 on HealthcareInformatics and is the direct responsibility of Subcommittee E31.25 on HealthcareData Management, Security, Confidentiality, and Privacy.Current edition approved Sept. 15, 2008. Published December 2008. Originallyapproved in 1995. Last previous edition ap
14、proved in 2001 as E 1715 01.2For referenced ASTM standards, visit the ASTM website, www.astm.org, orcontact ASTM Customer Service at serviceastm.org. For Annual Book of ASTMStandards volume information, refer to the standards Document Summary page onthe ASTM website.3Withdrawn. The last approved ver
15、sion of this historical standard is referencedon www.astm.org.4Available from American National Standards Institute (ANSI), 25 W. 43rd St.,4th Floor, New York, NY 10036, http:/www.ansi.org.5Available from Institute of Electrical and Electronics Engineers, Inc. (IEEE),445 Hoes Ln., P.O. Box 1331, Pis
16、cataway, NJ 08854-1331, http:/www.ieee.org.6Available from Health Level Seven, 900 Victors Way, Suite 122,AnnArbor, MI48108.1Copyright ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.now used in analysis. Entity-relationship modeling is onemajo
17、r technique used (1)7to establish the conceptual“ things”and their relationships involved in this overall functionaldomain. “Objects” (2, 3) is another term for these things, andthe object concept involves very specific characteristics asso-ciated with a defined object such as encapsulation and inhe
18、r-itance. Common ground exists between entity and objectrepresentations of models. However, the object terminology isstill evolving into a clearly established dictionary associatedwith object modeling at the analysis (2), design (3), andimplementation (3) levels of information systems engineering.4.
19、1.1 At the analysis level, which is most relevant toimplementation-independent standards creation, the static levelis first in importance since it identifies the involved objects andtheir static characteristics, such as definitions, relationships,and inheritance. Subsequently, the service/messages c
20、ommu-nication properties constitute the second level of importance,because they specify the dynamics of system behavior. How-ever, messages are more difficult to define since systembehavior patterns are more complex. This secondary domainalso involves the telecommunications aspects that are the focu
21、sof other standards bodies. Because of the distributed andnetworked architectures of the newest systems, telecommuni-cations may be of prime importance in qualifying the defini-tions of system behavior identified in Practice E 1239. For allof these reasons, it is of special importance to initially e
22、stablishan object-oriented static model for the RADT functionaldomain that can be the basis for definitions of healthcare datamanagement and standards setting and serve as a foundationfor modeling telecommunications standards.4.1.2 While this practice was being developed, a jointworking group (JWG)
23、on data modeling of the then AmericanNational Standards Institute (ANSI) Healthcare InformaticsStandards Planning Panel (HISPP), now Health InformaticsStandards Board (HISB), began work on a common data model(CDM) for the healthcare information domain. A JWG datamodeling convention document (IEEE 11
24、57.1) guides the con-ventions to be used, and this practice reflects those conventionsas they are currently known. It is intended that this practicecontribute to establishing the RADT core of the CDM. Theexact boundaries of the RADT functional domain have not yetbeen agreed on formally. The objects
25、included here are thosethat involve data generally associated with administrative anddemographic functions in patient care but that may also belinked with other functional domains involved with health care.4.2 Inclusion of Emergency Medical Systems FunctionsThis practice also takes note of the recen
26、t work of theemergency medical systems (EMS) standards ASTM Subcom-mittee F30.03.03 on Data Management Systems in defining thepre-hospital and associated emergency room data (GuideF 1629) required for emergency medical service system man-agement. The hospital and emergency room data are a subset oft
27、hat identified in Practice E 1384 and is consistent with thestatement of Steen and Dick (4) that EMS data are part of theprimary record of care. This concept has already been recog-nized in several state statutes that are part of the implementa-tion of an injury control plan by the Centers for Disea
28、seControl (see Practice E 1744). This RADT object modelpractice extends those data elements already defined in PracticeE 1384 by associating them with common RADT objects, asdefined here, that form the basis for a predictable systembehavior for trauma data. The behavior of clinical data will bedefin
29、ed subsequently in following standards.4.3 Relationships to Other SystemsThis practice alsoidentifies those objects in the RADT functional domain that arerequired by clinical laboratory information management sys-tems (CLIMS) (Guide E 1639), radiology information systems(RIS), and other ancillary sy
30、stems. This model also forms thecore for a basic ambulatory record system, and specializedvariants, in support of clinical specialties in medicine anddentistry. The object models for these ancillary and specializedelectronic health record (EHR) systems are defined in otherstandards that constitute t
31、he “family of models” that extend theRADT function.5. Significance and Use5.1 RADT Object Model as a Basis for CommunicationThe RADT object model is the first model used to create acommon library of consistent entities (objects) and theirattributes in the terminology of object analytical models asap
32、plied to the healthcare domain. These object models can beused to construct and refine standards relating to healt careinformation and its management. Since the RADT objectmodel underpins the design and implementation of specificsystems, it provides the framework for establishing the sys-tematics of
33、 managing observations made during health care.The observations recorded during health care not only becomethe basis for managing an individuals health care by practi-tioners but are also used for research and resource manage-ment. They define the common language for abstracting andcodifying observa
34、tions. The inconsistency and incompletenessof the data recorded in paper records is well known and hasbeen noted by the Institute of Medicines study (4). The abilityto build the recommended EHR begins with RADT, as noted inPractice E 1239. A more detailed specification of the RADTprocess and its spe
35、cific functional domain shall begin with aformal model. Furthermore, following agreement on the initialmodel, that model shall evolve as knowledge accumulates andthe initial view of the healthcare domain extends to other socialand psychologic processes that link healthcare with otherfunctional domai
36、ns of society. The management of lifelongcases of care, such as those of birth defects in newborns, willinvolve interactions with social work and educational func-tional domains of experience. It has been recognized for some7The boldface numbers in parentheses refer to the list of references at the
37、end ofthe standard.TABLE 1 Data Element DatatypesType Standard Tag/MnemonicName NameNumber NumCode CodeDatetime DtmSignature SigText TextQuantity QtyE 1715 01 (2008)2time (5) that a “healthcare team,” in the broader sense, isinvolved in dealing with these complex cases. The RADTmodel is the core to
38、linking these functional domains togetherin a transparent way. For that reason, the object terminology isused to enable the most global view and vernacular that willfacilitate communication among technical specialties that par-ticipate in managing some aspect of health care or that buildsystems to m
39、anage the required information.5.2 Common Terminology as a Basis for EducationTheuse of models and their associated terminology implies thateducation of the healthcare practitioners shall incorporate thisview to a significant extent. While a detailed specification ofsystems requires extensive lexico
40、ns of carefully defined terms,a more understandable terminology shall evolve for the processof educating practitioners during their formal education as wellas continuing to educate current practioners concerning howthis new technology can be integrated with their existingpractices. This challenge ha
41、s yet to be met, but the objects andmodeling concepts presented here are intended to be namedwith the most intuitive titles in order to promote clear under-standing during their use in instruction. Nevertheless, relatingthese objects and their properties to everyday practice remainsa significant cha
42、llenge, for both the implementors of systemsand educators. The perspectives cataloged here can be used inthe creation of system documentation and curricula representedin a variety of media.6. Graphic Representation6.1 The graphic representation in Figs. 1-4 of the relation-ships among the objects de
43、picts the static inheritance propertiesof the constituent objects. These properties and others, such asdefinitions, are given in tabular form in Section 7. Graphicdepiction provides a more comprehensive overview of theglobal structure of this functional domain, thus enabling thereader to appreciate
44、all of the parts of the model at a glance.This depiction also aids the reader when probing the specificattributes and other properties of the objects given in thetabular section. There are five object groups/subject areas (2),or subaggregates of objects with certain common characteris-tics. These re
45、lationships are more easily understood graphi-cally. The notation is from Coad and Yourdon (2). Two mainconcepts are involved. The first, represented by separate linesand arrowheads, is the “is a component of” relationship, whichimplies the parts of a whole. The second concept, representedby a branc
46、hing tree, is the “is a special case of” relationship,which implies encapsulation of the special attributes thatdifferentiate the individual characteristics of a more generalobject. The combination of these two relationships permits allof the complexities in the static interrelationships of theconst
47、ituent objects comprising the RADT model to be repre-sented. Instance connections are a weaker form of relationshipthat have not been included in the basic framework for thismodel. Instance connections show references to master systemtables of context-insensitive entities. These same terms appearin
48、the tabular representation. The sequential application ofthese relationships, visually from the top down in Figs. 1-4,depict the inheritance properties since the objects later in thesequence of the relationships inherit the attributes from thoseearlier in the sequence. These concepts are all explain
49、ed byCoad and Yourdon (2).7. Tabular Representation7.1 Tables 1 and 2 and Annex A1 provide the detailedattributes of the objects and should be compared with Table 1of Practice E 1239 and Annex A1 of Practice E 1384, whichshow the integrated logical structure of the computer-basedprimary record of care. The latest revision of Practice E 1384associates each data element with an index that uniquelyidentifies its segment location in Annex A1 and provides adefinition and references its representation. Certain data ele-ments with coded values have their value sets, which are
