ASTM E2369-2012 Standard Specification for Continuity of Care Record (CCR)《护理记录 (CCR) 连贯性的标准规范》.pdf

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

1、Designation: E2369 12 An 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.1. Scope1.1 The Continuity of Care Record (CCR) is a core data setof the most relevant administrative, demographic, and clinicalinfor

3、mation 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 anotherpractitioner, system, or setting to support the continuity of car

4、e.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 includesidentifying information and the purpose of the CCR. (See 5

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 specification is included. When prepared in a structuredelectron

6、ic 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 Guide for such representation.1.2 The primary use case fo

7、r the CCR is to provide asnapshot in time containing the pertinent clinical,demographic, 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 the implementationof use cases and workflows. Any examples

8、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 speci-fied XML coding provides flexibility that will allow user

9、s 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.It will further permit users to display the fields of the C

10、CR 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 moment in time. The CCRXML is not a persistent document, and it

11、 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 required XML schema in theAdjunct to thisspecification or other

12、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 healthcare information trans-mission with minimal workflow di

13、sruption 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 end-to-endCCR document integrity and confidentiality must be

14、 provided1This 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 Dec. 1, 2012. Published December 2012. Last prev

15、iousversion published 2002 as E236905e2. DOI: 10.1520/E2369-12.2A CCR 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

16、 patients record are followed. A personal health record, with the informationunder 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 AS

17、TM International Headquarters. Order Adjunct No.ADJE2369. Original adjunct 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

18、 of discharge, nor is it the transfer of anentire patient record.5The 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.Copyright ASTM International,

19、100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States1while conforming to regulations or other security,confidentiality, or privacy protections as applicable within thescope of this specification.1.4.1 Conditions of security and privacy for a CCR instancemust be establi

20、shed 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 document instance to permit access decisions to bemade based upon confide

21、ntiality 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-e

22、rability 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 (htt

23、p:/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 (PCRF) designed and mandated by the MassachusettsDepartment of Public Hea

24、lth 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. For example,the CCR insurance fields should not be construed to addre

25、ss 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 Manage-ment and Systems Society), the American Academy of FamilyPhysic

26、ians, 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(MoHCA), the Medical Group Management Association(MGMA) and the American

27、 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, other professional organizations, insurers,vendors, other healthcare inst

28、itutions, 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

29、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 Structure of the ElectronicHealth Record (EHR)E1762 Guide for Electroni

30、c 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 AuthorizationE1986 Guide for Information Access Privileges to HealthInformationE2

31、084 Specification for Authentication of Healthcare Infor-mation Using Digital Signatures (Withdrawn 2009)7E2085 Guide on Security Framework for Healthcare Infor-mation (Withdrawn 2009)7E2086 Guide for Internet and Intranet Healthcare Security(Withdrawn 2009)7E2147 Specification for Audit and Disclos

32、ure Logs for Usein Health Information SystemsE2182 Specification for Clinical XML DTDs in Healthcare(Withdrawn 2011)7E2183 Guide for XML DTD Design, Architecture andImplementation (Withdrawn 2011)7E2184 Specification for Healthcare Document Formats(Withdrawn 2011)7E2211 Specification for Relationshi

33、p Between a Person(Consumer) 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)

34、ICD-10-CM (http:/www.cdc.gov/nchs/icd/icd10cm.htm)LOINC (http:/www.loinc.org/)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 (ht

35、tp:/www.w3.org/TR/xmldsig-core/)W3C XML Encryption Standard (http:/www.w3.org/TR/xmlenc-core)2.3 ASTM Adjuncts:W3C XML Schema36For referenced ASTM standards, visit the ASTM website, www.astm.org, orcontact ASTM Customer Service at serviceastm.org. For Annual Book of ASTMStandards volume information,

36、 refer to the standards Document Summary page onthe ASTM website.7The last approved version of this historical standard is referenced onwww.astm.org.E2369 1223. Terminology3.1 Definitions of Terms Specific to This Standard:3.1.1 These terms also include the common terms seen inmany documents related

37、 to the CCR. See also Annex A1 fordefinitions of additional terms specific to this specification.3.1.2 actorsall the individuals, organizations, locations,and systems associated with the data in the CCR.3.1.3 attributefor the purposes of this specification, anattribute is a characteristic of data, r

38、epresenting 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.4 CCR bodycontains the core patient-specific data in aCCR, for example, Insurance, Medications, Problems,Proce

39、dures, and the like.3.1.5 CCR componentsCCR Header, CCR Body, CCRFooter; each component is made of sections, which in turn aremade up of data fields.3.1.6 CCR footercontains data defining all of the actors,as well as information about external references, all textcomments, and signatures associated

40、with any data within theCCR.3.1.7 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 directed, and the CCRspurpose.3.1.8 commentsall text comments a

41、ssociated with anydata within the CCR not containing core relevant, clinical, oradministrative data, and not containing pointers to referencesexternal to the CCR.3.1.9 CDAthe HL7 CDA (Clinical Document Architec-ture) is a document markup standard for the structure andsemantics of exchanged clinical

42、documents. E21823.1.10 complex data type or a groupconcepts used morethan once; defined by adding the post-fix Type.3.1.11 continuity of care record (CCR)a core data set ofthe most relevant administrative, demographic, and clinicalinformation facts about a patients healthcare, covering one ormore he

43、althcare 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.See Section 5 for a summary of CCR contents, and Annex A1for a

44、 detailed list of data fields.3.1.12 current procedural terminology (CPT)an annualreference published by the American Medical Association thatlists descriptive terms and identifying codes for reportingmedical services and procedures performed by physicians.3.1.13 data fieldsrequired or optional data

45、 within a sec-tion. Data fields may be repeated as often as necessary (seeAnnex A1).3.1.14 data objectsdiscrete patient-specific data(Medications, Problems, Procedures, and the like).3.1.15 DERFNCPDPs Data Element Request Form usedto request an addition or modification to NCPDPs current ornew standa

46、rds. www.ncpdp.org3.1.16 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, for example, by the recipient.E20843.1.17 DMRdurable medical equip

47、ment3.1.18 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.19 domain-specific applicationsadditional, optionalsets of CCR data elements specific to such areas as clinicalspecialties, institutions or ente

48、rprises, payers, diseasemanagement, and personal health records. Data sets for op-tional CCR domain-specific applications will be developed andballoted separately from this specification.3.1.20 element and attribute namesthe literal names of theXML tags (elements) and attributes of the XML tags (att

49、ri-butes).3.1.21 encounter(1) an interaction, regardless of thesetting, 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.22 enumerationthe process of limiting the alloweddata values wit