ASTM E1715-2001 Standard Practice for An Object-Oriented Model for Registration Admitting Discharge and Transfer (RADT) Functions in Computer-Based Patient Record Systems《计算机病人记录系统.pdf

《ASTM E1715-2001 Standard Practice for An Object-Oriented Model for Registration Admitting Discharge and Transfer (RADT) Functions in Computer-Based Patient Record Systems《计算机病人记录系统.pdf》由会员分享，可在线阅读，更多相关《ASTM E1715-2001 Standard Practice for An Object-Oriented Model for Registration Admitting Discharge and Transfer (RADT) Functions in Computer-Based Patient Record Systems《计算机病人记录系统.pdf（32页珍藏版）》请在麦多课文档分享上搜索。

1、Designation: E 1715 01An 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 immediately following

2、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 (e) indicates an editorial change since the last revision or reapproval.1. Scope1.1 This practice is inte

3、nded to amplify Guide E 1239 and tocomplement Guide E 1384 by detailing the objects that makeup the reservation, registration, admitting, discharge, andtransfer (RADT) functional domain of the computer-basedrecord of care (CPR). As identified in Guide E 1239, thisdomain is seminal to all patient rec

4、ord 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 management systems. The obj

5、ect 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 modeling concepts, system d

6、esign, 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:E 1238 Specification for Transferring Clinical ObservationsBetween Independent Computer Systems2E 1239 Guide for Description of Reservat

7、ion/Registration-Admission, Discharge, Transfer (RADT) Systems for Au-tomated Patient Care Information Systems2E 1384 Guide for Content and Structure of the ElectronicHealth Record (EHR)2E 1633 Specification for Coded Values Used in the Elec-tronic Health Record (EHR)2E 1639 Guide for Functional Req

8、uirements of ClinicalLaboratory Information Management Systems2E 1744 Guide for View of Emergency Medical Care in theComputerized Patient Record2F 1629 Guide for Establishing and/or Operating EmergencyMedical Services Management Information Systems32.2 ANSI Standard:ANSI X3.172 Dictionary of Informa

9、tion 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.3.2 Definitions of Term

10、s 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, and the management ofre

11、sources enabling that care to be delivered. (HL-7, v2.4)4. Background4.1 Object Representation of RADT ProcessesGuideE 1239 provides the experiential background of the functionsin RADT. These functions are common to all systems that dealwith patient data. The minimal essential data elements forRADT

12、were identified and characterized partly in GuideE 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 arenow used in analysis. Entity-relationship modeling is onemajo

13、r technique used (1)7to establish the conceptual“ things”and their relationships involved in this overall functional1This practice is under the jurisdiction of ASTM Committee E31 on HealthcareInformatics and is the direct responsibility of Subcommittee E31.25 on HealthcareManagement, Security, Confi

14、dentiality, and Privacy.Current edition approved May 10, 2001. Published July 2001. Originallypublished as E 174495. Last previous edition E 174499.2Annual Book of ASTM Standards, Vol 14.01.3Annual Book of ASTM Standards, Vol 13.01.4Available from American National Standards Institute, 11 W. 42nd St

15、., 13thFloor, New York, NY 10036.5Available from IEEE, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ08855-1331.6Available from Health Level Seven, 900 Victors Way, Suite 122,AnnArbor, MI48108.7The boldface numbers in parentheses refer to the list of references at the end ofthe standard.1Copyright AST

16、M International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.domain. “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 inher-itance. Commo

17、n 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.1.1 At the anal

18、ysis 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 commu-nication p

19、roperties 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 focusof other stand

20、ards 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 Guide E 1239. For all ofthese reasons, it is of special importance to initially establish anobject-

21、oriented static model for the RADT functional domainthat can be the basis 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

22、 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 1157.1) guides the

23、 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 included here ar

24、e 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 recent work of theeme

25、rgency 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 ofthat identified i

26、n Guide 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 DiseaseControl (see Guid

27、e E 1744). This RADT object model practiceextends those data elements already defined in Guide E 1384by associating them with common RADT objects, as definedhere, that form the basis for a predictable system behavior fortrauma data. The behavior of clinical data will be definedsubsequently in follow

28、ing 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 systems. This model also fo

29、rms 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 the “family of models” tha

30、t 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 asapplied to the healthcare d

31、omain. 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 managing observations ma

32、de 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 observations. The inconsistency

33、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 inGuide E 1239. A more detailed specification of the RADTprocess and its specific functional domain shal

34、l 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 domains of society. The managemen

35、t 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 sometime (5) that a “healthcare team,” in the broader sense, isinvolved in dealing with these complex cases.

36、 The RADTmodel is the core to linking these functional domains togetherin a transparent way. For that reason, the object terminology isused to enable the most global view and vernacular that willTABLE 1 Data Element DatatypesType Standard Tag/MnemonicName NameNumber NumCode CodeDatetime DtmSignature

37、 SigText TextQuantity QtyE1715012facilitate 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 and their associated terminology impl

38、ies 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 educating practitioners during their

39、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 namedwith the most intuitive titles in order

40、 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 be used inthe creation of system docu

41、mentation 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, such asdefinitions, are given in tab

42、ular 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 specificattributes and other properti

43、es 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). Two mainconcepts are involved. The f

44、irst, 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 special attributes thatdifferentiate the in

45、dividual 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 weaker form of relationshipthat have not bee

46、n 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 the top down in Figs. 1-4,depict the inh

47、eritance 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

48、 should be compared with Table 1of Guide E 1239 and Annex A1 of Guide E 1384, which showthe integrated logical structure of the computer-based primaryrecord of care. The latest revision of Guide E 1384 associateseach data element with an index that uniquely identifies itssegment location in Annex A1

49、 and provides a definition andreferences its representation. Certain data elements with codedvalues have their value sets, which are also identified in thatspecification by its specific index contained in Guide E 1384and point to Specification E 1633. The definitions, mnemonics,and associated attributes of the objects in the RADT objectmodel are given in Table A1.1 of Annex A1 of this practice.The object mnemonics that are used in the construction ofstandardized short names for the data elements indexed andcharacterized in Guide E 1384 are given as attributes in thispractice.