1、Designation: E 2369 051An American National StandardStandard Specification forContinuity of Care Record (CCR)1This standard is issued under the fixed designation E 2369; the number immediately following the designation indicates the year oforiginal adoption or, in the case of revision, the year of l
2、ast 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.1. Scope1.1 The Continuity of Care Record (CCR) is a core data setof the mo
3、st 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 thepertinent data about a patient and forward it to anotherpractit
4、ioner, 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, caredocumentation, and the patients care plan. It also includes
5、identifying 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 electronically, provided the information requiredby this specif
6、ication 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 a W3C XML schema and Annex A2contains an Implementation
7、 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 use cases orto workflows, but is intended to facilitate
8、 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 is created in a structured electronic format.5This spe
9、ci-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 file, as an HTML file, or as a word processing document
10、.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, demographic,and clinical information at a specific mom
11、ent 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 Implementation Guide (see Annex A2).1.3.2 Using the requ
12、ired 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 able to import and export allCCR data to enable automated
13、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.1.4 SecurityThe data contained within the CCR are pa-tient data and, if those data are identifiable, then
14、 end-to-end1This specification is under the jurisdiction of ASTM Committee E31 onHealthcare Informatics and is the direct responsibility of Subcommittee E31.25 onHealthcare Data Management, Security, Confidentiality, and Privacy.Current edition approved July 17, 2006. Published December 2006.2A CCR
15、is not intended to be a medical-legal 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 info
16、rmationunder the control of the patient 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 adj
17、unct produced in 2006.4Since the CCR 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
18、required XML may be as represented in 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,
19、 United States.CCR 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.1 Conditions of security and privacy for a CCR instancemust be established in
20、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 document instance to permit access decisions to bemade based upon confidentiality
21、 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 specific CCRuse cases. When a specification is necessary to assure interop-erability
22、 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 that require digital signatures, W3CsXML digital signature standard (http:/www.w
23、3.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 (PCRF) designed and mandated by the MassachusettsDepartment of Public Health for
24、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. For example,the CCR insurance fields should not be construed to address allre
25、imbursement, 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 Manage-ment and Systems Society), the American Academy of FamilyPhysicians, th
26、eAmericanAcademy 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(MoHCA), the Medical Group Management Association(MGMA) and the American College
27、 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, other professional organizations, insurers,vendors, other healthcare institutions
28、, 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 to establish appro-priate safety and health practices and determine the applica-
29、bility of regulatory limitations prior to use.2. Referenced Documents2.1 ASTM Standards:6E 1382 Test Methods for Determining Average Grain SizeUsing Semiautomatic and Automatic Image AnalysisE 1384 Practice for Content and Structure of the ElectronicHealth Record (EHR)E 1762 Guide for Electronic Aut
30、hentication of Health CareInformationE 1869 Guide for Confidentiality, Privacy,Access, and DataSecurity Principles for Health Information Including Elec-tronic Health RecordsE 1985 Guide for User Authentication and AuthorizationE 1986 Guide for Information Access Privileges to HealthInformationE 208
31、4 Specification for Authentication of Healthcare In-formation Using Digital SignaturesE 2085 Guide on Security Framework for Healthcare Infor-mationE 2086 Guide for Internet and Intranet Healthcare SecurityE 2147 Specification for Audit and Disclosure Logs for Usein Health Information SystemsE 2182
32、Specification for Clinical XML DTDs in HealthcareE 2183 Guide for XML DTD Design, Architecture, andImplementationE 2184 Specification for Healthcare Document FormatsE 2211 Specification for Relationship Between a Person(Consumer) and a Supplier of an Electronic Personal(Consumer) Health RecordE 2212
33、 Specification for Health 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/)Massachusetts Department of Health Patient Care ReferralFormNDC (http
34、:/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/TR/xmlenc-core)2.3 ASTM Adjuncts:W3C XML Schema33. Terminology3.1 Def
35、initions of Terms Specific to This StandardTheseterms also include the common terms seen in many documentsrelated to the CCR. See also Annex A1 for definitions ofadditional terms specific to this specification.6For referenced ASTM standards, visit the ASTM website, www.astm.org, orcontact ASTM Custo
36、mer Service at serviceastm.org. For Annual Book of ASTMStandards volume information, refer to the standards Document Summary page onthe ASTM website.E236905123.1.1 actorsall the individuals, organizations, locations,and systems associated with the data in the CCR.3.1.2 attributefor the purposes of t
37、his specification, anattribute is a characteristic of data, representing one or moreaspects, descriptors, or elements of the data. In object-orientedsystems, attributes are characteristics of objects. In XML,attributes are characteristics of tags.3.1.3 CCR bodycontains the core patient-specific data
38、 in aCCR, for example, Insurance, Medications, Problems, Proce-dures, and the like.3.1.4 CCR componentsCCR Header, CCR Body, CCRFooter; 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 ex
39、ternal references, all textcomments, and signatures associated with any data within theCCR.3.1.6 CCR headerdefines the document parameters, 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
40、directed, and the CCRspurpose.3.1.7 commentsall text comments associated with anydata within the CCR not containing core relevant, clinical, 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
41、 standard for the structure andsemantics of exchanged clinical documents. E 21823.1.9 complex data type or a groupconcepts used morethan 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 clinicalinform
42、ation facts about a patients healthcare, covering one ormore healthcare encounters. It provides a means for onehealthcare practitioner, 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
43、.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)an annualreference published by the American Medical Association thatlists descriptive terms and identifying codes for reportingmedical services and procedures perf
44、ormed by physicians.3.1.12 data fieldsrequired or optional data within a sec-tion. Data fields may be repeated as often as necessary (seeAnnex 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 r
45、equest an addition or modification to NCPDPs current ornew standards. www.ncpdp.org3.1.15 digital signaturedata associated with, or a crypto-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, f
46、or example, by the recipient.E 20843.1.16 DMRdurable medical equipment3.1.17 document objectthe CCR as an XML document,consisting of a header, 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 s
47、pecific to such areas as clinicalspecialties, institutions or enterprises, payers, disease manage-ment, and personal health records. Data sets for optional CCRdomain-specific applications will be developed and ballotedseparately from this specification.3.1.19 element and attribute namesthe literal n
48、ames ofthe XML tags (elements) and attributes of the XML tags(attributes).3.1.20 encounter(1) an interaction, regardless of the set-ting, between a patient and a practitioner who is vested withprimary responsibility for diagnosing, evaluating, or treatingthe patients condition. It may include visits
49、, 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. E 13843.1.21 enumerationthe process of limiting the alloweddata values within a defined set of XML tags to a defined andconstrained list, an enumerated list.3.1.22 electronic health record (EHR)any informationrelated to the physical or mental health/condition of anindividual that resides in electronic s
