1、Designation: E1715 01 (Reapproved 2013) 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 E1715; the number immed
2、iately 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 E1239 andto complement Practice E1384 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 E1239, thisdomain is semi
4、nal 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 manag
5、ement 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 model
6、ing 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:2E1238 Specification for Transferring Clinical ObservationsBetween Independent Computer Systems (Withdrawn2002)3E1
7、239 Practice for Description of Reservation/Registration-Admission, Discharge, Transfer (R-ADT) Systems forElectronic Health Record (EHR) SystemsE1384 Practice for Content and Structure of the ElectronicHealth Record (EHR)E1633 Specification for Coded Values Used in the ElectronicHealth RecordE1639
8、Guide for Functional Requirements of Clinical Labo-ratory Information Management Systems (Withdrawn2002)3E1744 Practice for View of Emergency Medical Care in theElectronic Health RecordF1629 Guide for Establishing Operating Emergency Medi-cal Services and Management Information Systems, orBoth (With
9、drawn 2015)32.2 ANSI Standard:ANSI X3.172 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 ar
10、e defined in accordancewith ANSI X3.172.3.2 Definitions of Terms Specific to This Standard:3.2.1 functional domain, nthat area of activity that encom-passes 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 p
11、reven-tive and corrective, to patients, and the management ofresources enabling that care to be delivered. (HL-7, v2.4)4. Background4.1 Object Representation of RADT ProcessesPracticeE1239 provides the experiential background of the functions inRADT. These functions are common to all systems that de
12、alwith patient data. The minimal essential data elements for1This practice is under the jurisdiction 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 Ma
13、rch 01, 2013. Published March 2013. Originallyapproved in 1995. Last previous edition approved in 2008 as E1715 01(2008).DOI: 10.1520/E1715-01R13.2For referenced ASTM standards, visit the ASTM website, www.astm.org, orcontact ASTM Customer Service at serviceastm.org. For Annual Book of ASTMStandards
14、 volume information, refer to the standards Document Summary page onthe ASTM website.3The last approved version of this historical standard is referenced onwww.astm.org.4Available from American National Standards Institute (ANSI), 25 W. 43rd St.,4th Floor, New York, NY 10036, http:/www.ansi.org.5Ava
15、ilable from Institute of Electrical and Electronics Engineers, Inc. (IEEE),445 Hoes Ln., P.O. Box 1331, Piscataway, NJ 08854-1331, http:/www.ieee.org.6Available from Health Level Seven, 900 Victors Way, Suite 122,AnnArbor, MI48108.Copyright ASTM International, 100 Barr Harbor Drive, PO Box C700, Wes
16、t Conshohocken, PA 19428-2959. United StatesNOTICE: This standard has either been superseded and replaced by a new version or withdrawn.Contact ASTM International (www.astm.org) for the latest information1RADT were identified and characterized partly in PracticeE1239. Table 1 of that guide identifie
17、s a logical data structurefor the data elements, but it does not relate these elements toconstituent “entities” or “objects” in the sense that they arenow used in analysis. Entity-relationship modeling is onemajor technique used (1)7to establish the conceptual“ things”and their relationships involve
18、d 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 inheri-tance. Common ground exists between entity and objectrepresentations of models. Howev
19、er, 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.1.1 At the analysis level, which is most relevant toimplementation-independent standards
20、 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 commu-nication properties constitute the second level of importance,because they specify
21、the dynamics of system behavior.However, messages are more difficult to define since systembehavior patterns are more complex. This secondary domainalso involves the telecommunications aspects that are the focusof other standards bodies. Because of the distributed andnetworked architectures of the n
22、ewest systems, telecommuni-cations may be of prime importance in qualifying the defini-tions of system behavior identified in Practice E1239. For all ofthese reasons, it is of special importance to initially establish anobject-oriented static model for the RADT functional domainthat can be the basis
23、 for definitions of healthcare data manage-ment and standards setting and serve as a foundation formodeling telecommunications standards.4.1.2 While this practice was being developed, a jointworking group (JWG) on data modeling of the then AmericanNational Standards Institute (ANSI) Healthcare Infor
24、maticsStandards 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 1157.1) guides theconventions to be used, and this practice reflects those conven-tions as
25、they are currently known. It is intended that thispractice contribute to establishing the RADT core of the CDM.The exact boundaries of the RADT functional domain have notyet been agreed on formally. The objects included here arethose that involve data generally associated with administrativeand demo
26、graphic 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 recent work of theemergency medical systems (EMS) standards ASTM Subcom-mittee F30.03.03 on Da
27、ta Management Systems in defining thepre-hospital and associated emergency room data (GuideF1629) required for emergency medical service system man-agement. The hospital and emergency room data are a subset ofthat identified in Practice E1384 and is consistent with thestatement of Steen and Dick (4)
28、 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 DiseaseControl (see Practice E1744). This RADT object model prac-tice extends those data element
29、s already defined in PracticeE1384 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 bedefined subsequently in following standards.4.3 Relationships to Other SystemsThis practice also
30、identifies those objects in the RADT functional domain that arerequired by clinical laboratory information management sys-tems (CLIMS) (Guide E1639), radiology information systems(RIS), and other ancillary systems. This model also forms thecore for a basic ambulatory record system, and specializedva
31、riants, 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 the “family of models” that extend theRADT function.5. Significance and Use5.1 RADT Object Mo
32、del 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 asapplied to the healthcare domain. These object models can beused to construct and refine stand
33、ards 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 managing observations made during health care.The observations recorded during health care
34、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 observations. The inconsistency and incompletenessof the data recorded in paper records is well kno
35、wn and hasbeen noted by the Institute of Medicines study (4). The abilityto build the recommended EHR begins with RADT, as noted inPractice E1239. A more detailed specification of the RADTprocess and its specific functional domain shall begin with aformal model. Furthermore, following agreement on t
36、he initialmodel, that model shall evolve as knowledge accumulates andthe initial view of the healthcare domain extends to other social7The boldface numbers in parentheses refer to the list of references at the end ofthe standard.TABLE 1 Data Element DatatypesType Standard Tag/MnemonicName NameNumber
37、 NumCode CodeDatetime DtmSignature SigText TextQuantity QtyE1715 01 (2013)2and psychologic processes that link healthcare with otherfunctional domains of society. The management of lifelongcases of care, such as those of birth defects in newborns, willinvolve interactions with social work and educat
38、ional func-tional domains of experience. It has been recognized for sometime (5) that a “healthcare team,” in the broader sense, isinvolved in dealing with these complex cases. The RADTmodel is the core to linking these functional domains togetherin a transparent way. For that reason, the object ter
39、minology 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 manage the required information.5.2 Common Terminology as a Basis for EducationTheuse of models
40、 and their associated terminology implies thateducation of the healthcare practitioners shall incorporate thisview to a significant extent. While a detailed specification ofsystems requires extensive lexicons of carefully defined terms,a more understandable terminology shall evolve for the processof
41、 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 has yet to be met, but the objects andmodeling concepts presented here are intended to be namedw
42、ith 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 challenge, for both the implementors of systemsand educators. The perspectives cataloged here can
43、 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 depicts the static inheritance propertiesof the constituent objects. These properties and others
44、, 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 all of the parts of the model at a glance.This depiction also aids the reader when probing the
45、 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 relationships are more easily understood graphi-cally. The notation is from Coad and Yourdon (2
46、). 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 branching tree, is the “is a special case of” relationship,which implies encapsulation of the spec
47、ial attributes thatdifferentiate the individual characteristics of a more generalobject. The combination of these two relationships permits allof the complexities in the static interrelationships of theconstituent objects comprising the RADT model to be repre-sented. Instance connections are a weake
48、r 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 the tabular representation. The sequential application ofthese relationships, visually from t
49、he 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 explained 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 E1239 and Annex A1 of Practice E1384, whichshow the integrated logical structure of the computer-basedprimary record of care. The latest revision of Practice E1384associates each data
