ASTM E2369-2005e2 Standard Specification for Continuity of Care Record (CCR)《护理记录连续性(CCR)的标准规格》.pdf

《ASTM E2369-2005e2 Standard Specification for Continuity of Care Record (CCR)《护理记录连续性(CCR)的标准规格》.pdf》由会员分享，可在线阅读，更多相关《ASTM E2369-2005e2 Standard Specification for Continuity of Care Record (CCR)《护理记录连续性(CCR)的标准规格》.pdf（100页珍藏版）》请在麦多课文档分享上搜索。

1、Designation: E2369 052An American National StandardStandard Specification forContinuity of Care Record (CCR)1This standard is issued under the fixed designation E2369; the number immediately following the designation indicates the year oforiginal adoption or, in the case of revision, the year of las

2、t revision. A number in parentheses indicates the year of last reapproval. Asuperscript epsilon () indicates an editorial change since the last revision or reapproval.1NOTESection 2 was corrected editorially in August 2009.2NOTEFootnote 1 was corrected editorially in October 20111. Scope1.1 The Cont

3、inuity of Care Record (CCR) is a core data setof the most relevant administrative, demographic, and clinicalinformation facts about a patients healthcare, covering one ormore healthcare encounters.2It provides a means for onehealthcare practitioner, system, or setting to aggregate all of thepertinen

4、t data about a patient and forward it to anotherpractitioner, system, or setting to support the continuity of care.1.1.1 The CCR data set includes a summary of the patientshealth status (for example, problems, medications, allergies)and basic information about insurance, advance directives, caredocu

5、mentation, and the patients care plan. It also includesidentifying information and the purpose of the CCR. (See 5.1for a description of the CCRs components and sections, andAnnex A1 for the detailed data fields of the CCR.)1.1.2 The CCR may be prepared, displayed, and transmittedon paper or electron

6、ically, provided the information requiredby this specification is included. When prepared in a structuredelectronic format, strict adherence to an XML schema and anaccompanying implementation guide is required to supportstandards-compliant interoperability. The Adjunct3to thisspecification contains

7、a W3C XML schema and Annex A2contains an Implementation Guide for such representation.1.2 The primary use case for the CCR is to provide asnapshot in time containing the pertinent clinical, demo-graphic, and administrative data for a specific patient.1.2.1 This specification does not speak to other

8、use cases orto workflows, but is intended to facilitate the implementationof use cases and workflows. Any examples offered in thisspecification are not to be considered normative.41.3 To ensure interchangeability of electronic CCRs, thisspecification specifies XML coding that is required when theCCR

9、 is created in a structured electronic format.5This speci-fied XML coding provides flexibility that will allow users toprepare, transmit, and view the CCR in multiple ways, forexample, in a browser, as an element in a Health Level 7 (HL7)message or CDA compliant document, in a secure email, as aPDF

10、file, as an HTML file, or as a word processing document.It will further permit users to display the fields of the CCR inmultiple formats.1.3.1 The CCR XML schema or .xsd (see theAdjunct to thisspecification) is defined as a data object that represents asnapshot of a patients relevant administrative,

11、 demographic,and clinical information at a specific moment in time. The CCRXML is not a persistent document, and it is not a messagingstandard.NOTE 1The CCR XML schema can also be used to define an XMLrepresentation for the CCR data elements, subject to the constraintsspecified in the accompanying I

12、mplementation Guide (see Annex A2).1.3.2 Using the required XML schema in the Adjunct to thisspecification or other XML schemas that may be authorizedthrough joints efforts of ASTM and other standards develop-ment organizations, properly designed electronic healthcarerecord (EHR) systems will be abl

13、e to import and export allCCR data to enable automated healthcare information trans-mission with minimal workflow disruption for practitioners.Equally important, it will allow the interchange of the CCRdata between otherwise incompatible EHR systems.1This specification is under the jurisdiction of A

14、STM Committee E31 onHealthcare Informatics and is the direct responsibility of Subcommittee E31.25 onHealthcare Data Management, Security, Confidentiality, and Privacy.Current edition approved Oct. 1, 2005. Published December 2005. DOI:10.1520/E2369-05E02.2A CCR is not intended to be a medical-legal

15、 clinical or administrativedocument entered into a patients record, but may in specific use cases be used insuch a manner, provided that accepted policies and procedures in adding such datato a patients record are followed. A personal health record, with the informationunder the control of the patie

16、nt or their designated representative, would be anexample of such a use case, as would be importation into an electronic health recordsystem, a data repository, or a registry.3Available from ASTM International Headquarters. Order Adjunct No.ADJE2369. Original adjunct produced in 2006.4Since the CCR

17、is a core data set of selected, relevant information, it is not adischarge summary, that is, it does not include all of a patients health informationthat would be routinely recorded at the time of discharge, nor is it the transfer of anentire patient record.5The required XML may be as represented in

18、 the Adjunct to this specification orAnnex A2 or other XML representation made possible through joint efforts ofASTM and other standards development organizations.1Copyright ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.1.4 SecurityThe data c

19、ontained within the CCR are pa-tient data and, if those data are identifiable, then end-to-endCCR document integrity and confidentiality must be providedwhile conforming to regulations or other security, confidenti-ality, or privacy protections as applicable within the scope ofthis specification.1.4

20、.1 Conditions of security and privacy for a CCR instancemust be established in a way that allows only properlyauthenticated and authorized access to the CCR documentinstance or its elements. The CCR document instance must beself-protecting when possible, and carry sufficient data embed-ded in the do

21、cument instance to permit access decisions to bemade based upon confidentiality constraints or limitationsspecific to that instance.1.4.2 Additional Subcommittee E31.20 on Security andPrivacy guides, practices, and specifications will be publishedin support of the security and privacy needs of speci

22、fic CCRuse cases. When a specification is necessary to assure interop-erability or other required functionality, the CCR core schemawill be extended to meet the profile requirements of theunderlying use case, building upon existing standards andspecifications whenever possible.1.4.2.1 For profiles t

23、hat require digital signatures, W3CsXML digital signature standard (http:/www.w3.org/TR/xmldsig-core) will be used with digital certificates. Encryptionwill be provided using W3Cs XML encryption standard(http:/www.w3.org/TR/xmlenc-core).1.5 The CCR is an outgrowth of the Patient Care ReferralForm (P

24、CRF) designed and mandated by the MassachusettsDepartment of Public Health for use primarily in inpatientsettings.1.5.1 Unlike the PCRF, the CCR is designed for use in allclinical care settings.1.6 It is assumed that information contained in a CCR willbe confirmed as appropriate in clinical practice

25、. For example,the CCR insurance fields should not be construed to address allreimbursement, authorization, or eligibility issues, and currentmedications and other critical data should be validated.1.7 Committee E31 gratefully acknowledges the Massachu-setts Medical Society, HIMSS (Health Information

26、 Manage-ment and Systems Society), the American Academy of FamilyPhysicians, theAmericanAcademy of Pediatrics, theAmericanMedical Association, the Patient Safety Institute, the AmericanHealth Care Association, the National Association for theSupport of Long Term Care, the Mobile Healthcare Alliance(

27、MoHCA), the Medical Group Management Association(MGMA) and the American College of Osteopathic FamilyPhysicians (ACOFP) as co-leaders with ASTM in the stan-dards development and adoption, and joins them in invitingthe collaboration of all stakeholders, including other clinicalspecialty societies, ot

28、her professional organizations, insurers,vendors, other healthcare institutions, departments of publichealth, and other government agencies.1.8 This standard does not purport to address all of thesafety concerns, if any, associated with its use. It is theresponsibility of the user of this standard t

29、o establish appro-priate safety and health practices and determine the applica-bility of regulatory limitations prior to use.2. Referenced Documents2.1 ASTM Standards:6E1382 Test Methods for Determining Average Grain SizeUsing Semiautomatic and Automatic Image AnalysisE1384 Practice for Content and

30、Structure of the ElectronicHealth Record (EHR)E1762 Guide for Electronic Authentication of Health CareInformationE1869 Guide for Confidentiality, Privacy, Access, and DataSecurity Principles for Health Information Including Elec-tronic Health RecordsE1985 Guide for User Authentication and Authorizat

31、ionE1986 Guide for Information Access Privileges to HealthInformationE2084 Specification for Authentication of Healthcare Infor-mation Using Digital Signatures7E2085 Guide on Security Framework for Healthcare Infor-mation7E2086 Guide for Internet and Intranet Healthcare Security7E2147 Specification

32、for Audit and Disclosure Logs for Usein Health Information SystemsE2182 Specification for Clinical XML DTDs in Healthcare7E2183 Guide for XML DTD Design, Architecture andImplementation7E2184 Specification for Healthcare Document Formats7E2211 Specification for Relationship Between a Person(Consumer)

33、 and a Supplier of an Electronic Personal(Consumer) Health RecordE2212 Practice for Healthcare Certificate Policy2.2 Other References:Health Information Portability and Accountability Act, U.S.Congress, 1996ICD-9-CM (http:/www.cdc.gov/nchs/about/otheract/icd9/abticd9.htm)LOINC (http:/www.loinc.org/)

34、Massachusetts Department of Health Patient Care ReferralFormNDC (http:/www.fda.gov/cder/ndc/)RxNorm (http:/www.nlm.nih.gov/research/umls/rxnorm-_main.html)SNOMED (http:/www.snomed.org/)W3C XML Digital Signature Standard (http:/www.w3.org/TR/xmldsig-core/)W3C XML Encryption Standard (http:/www.w3.org

35、/TR/xmlenc-core)2.3 ASTM Adjuncts:W3C XML Schema33. Terminology3.1 Definitions of Terms Specific to This StandardTheseterms also include the common terms seen in many documents6For referenced ASTM standards, visit the ASTM website, www.astm.org, orcontact ASTM Customer Service at serviceastm.org. Fo

36、r Annual Book of ASTMStandards volume information, refer to the standards Document Summary page onthe ASTM website.7Withdrawn. The last approved version of this historical standard is referencedon www.astm.org.E2369 0522related to the CCR. See also Annex A1 for definitions ofadditional terms specifi

37、c to this specification.3.1.1 actorsall the individuals, organizations, locations,and systems associated with the data in the CCR.3.1.2 attributefor the purposes of this specification, anattribute is a characteristic of data, representing one or moreaspects, descriptors, or elements of the data. In

38、object-orientedsystems, attributes are characteristics of objects. In XML,attributes are characteristics of tags.3.1.3 CCR bodycontains the core patient-specific data in aCCR, for example, Insurance, Medications, Problems, Proce-dures, and the like.3.1.4 CCR componentsCCR Header, CCR Body, CCRFooter

39、; each component is made of sections, which in turn aremade up of data fields.3.1.5 CCR footercontains data defining all of the actors,as well as information about external references, all textcomments, and signatures associated with any data within theCCR.3.1.6 CCR headerdefines the document parame

40、ters, in-cluding its unique identifier, language, version, date/time, thepatient whose data it contains, who or what has generated theCCR, to whom or what the CCR is directed, and the CCRspurpose.3.1.7 commentsall text comments associated with anydata within the CCR not containing core relevant, cli

41、nical, oradministrative data, and not containing pointers to referencesexternal to the CCR.3.1.8 CDAthe HL7 CDA (Clinical Document Architec-ture) is a document markup standard for the structure andsemantics of exchanged clinical documents. E21823.1.9 complex data type or a groupconcepts used moretha

42、n once; defined by adding the post-fix Type.3.1.10 continuity of care record (CCR)a core data set ofthe most relevant administrative, demographic, and clinicalinformation facts about a patients healthcare, covering one ormore healthcare encounters. It provides a means for onehealthcare practitioner,

43、 system, or setting to aggregate all of thepertinent data about a patient and forward it to anotherpractitioner, system, or setting to support the continuity of care.See Section 5 for a summary of CCR contents, and Annex A1for a detailed list of data fields.3.1.11 current procedural terminology (CPT

44、)an annualreference published by the American Medical Association thatlists descriptive terms and identifying codes for reportingmedical services and procedures performed by physicians.3.1.12 data fieldsrequired or optional data within a sec-tion. Data fields may be repeated as often as necessary (s

45、eeAnnex A1).3.1.13 data objectsdiscrete patient-specific data (Medica-tions, Problems, Procedures, and the like).3.1.14 DERFNCPDPs Data Element Request Form usedto request an addition or modification to NCPDPs current ornew standards. www.ncpdp.org3.1.15 digital signaturedata associated with, or a c

46、rypto-graphic transformation of, a data unit that allows a recipient ofthe data unit to prove the source and integrity of the data unitand protect against forgery, for example, by the recipient.E20843.1.16 DMRdurable medical equipment3.1.17 document objectthe CCR as an XML document,consisting of a h

47、eader, a body, and a footer, each built from aset of discrete XML building blocks.3.1.18 domain-specific applicationsadditional, optionalsets of CCR data elements specific to such areas as clinicalspecialties, institutions or enterprises, payers, disease manage-ment, and personal health records. Dat

48、a sets for optional CCRdomain-specific applications will be developed and ballotedseparately from this specification.3.1.19 element and attribute namesthe literal names ofthe XML tags (elements) and attributes of the XML tags(attributes).3.1.20 encounter(1) an interaction, regardless of the set-ting

49、, between a patient and a practitioner who is vested withprimary responsibility for diagnosing, evaluating, or treatingthe patients condition. It may include visits, appointments, aswell as non face-to-face interactions; and (2) a contact betweena patient and a practitioner who has primary responsibility forassessing and treating the patient at a given contact, exercisingindependent judgment. E13843.1.21 enumerationthe process of limiting the alloweddata values within a defined set of XML tags to a defined andconstrained list, a