Abstract
The Continuity of Care Record (CCR) is a core data set of the most relevant administrative, demographic, and clinical information facts about a patient�s healthcare, covering one or more healthcare encounters. It provides a means for one healthcare practitioner, system, or setting to aggregate all of the pertinent data about a patient and forward it to another practitioner, system, or setting to support the continuity of care. The primary use case for the CCR is to provide a snapshot in time containing the pertinent clinical, demographic, and administrative data for a specific patient. To ensure interchangeability of electronic CCRs, this specification specifies XML coding that is required when the CCR is created in a structured electronic format. Conditions of security and privacy for a CCR instance must be established in a way that allows only properly authenticated and authorized access to the CCR document instance or its elements. The CCR consists of three core components: the CCR Header, the CCR Body, and the CCR Footer.
Scope
1.1 The Continuity of Care Record (CCR) is a core data set of the most relevant administrative, demographic, and clinical information facts about a patient’s healthcare, covering one or more healthcare encounters.2 It provides a means for one healthcare practitioner, system, or setting to aggregate all of the pertinent data about a patient and forward it to another practitioner, system, or setting to support the continuity of care.
1.1.1 The CCR data set includes a summary of the patient’s health status (for example, problems, medications, allergies) and basic information about insurance, advance directives, care documentation, and the patient’s care plan. It also includes identifying information and the purpose of the CCR. (See 5.1 for a description of the CCR’s components and sections, and Annex A1 for the detailed data fields of the CCR.)
1.1.2 The CCR may be prepared, displayed, and transmitted on paper or electronically, provided the information required by this specification is included. When prepared in a structured electronic format, strict adherence to an XML schema and an accompanying implementation guide is required to support standards-compliant interoperability. The Adjunct3 to this specification contains a W3C XML schema and Annex A2 contains an Implementation Guide for such representation.
1.2 The primary use case for the CCR is to provide a snapshot 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 or to workflows, but is intended to facilitate the implementation of use cases and workflows. Any examples offered in this specification are not to be considered normative.4
1.3 To ensure interchangeability of electronic CCRs, this specification specifies XML coding that is required when the CCR is created in a structured electronic format.5 This specified XML coding provides flexibility that will allow users to prepare, transmit, and view the CCR in multiple ways, for example, in a browser, as an element in a Health Level 7 (HL7) message or CDA compliant document, in a secure email, as a PDF file, as an HTML file, or as a word processing document. It will further permit users to display the fields of the CCR in multiple formats.
1.3.1 The CCR XML schema or .xsd (see the Adjunct to this specification) is defined as a data object that represents a snapshot of a patient’s relevant administrative, demographic, and clinical information at a specific moment in time. The CCR XML is not a persistent document, and it is not a messaging standard.
1.3.2 Using the required XML schema in the Adjunct to this specification or other XML schemas that may be authorized through joints efforts of ASTM and other standards development organizations, properly designed electronic healthcare record (EHR) systems will be able to import and export all CCR data to enable automated healthcare information transmission with minimal workflow disruption for practitioners. Equally important, it will allow the interchange of the CCR data between otherwise incompatible EHR systems.
1.4 Security—The data contained within the CCR are patient data and, if those data are identifiable, then end-to-end CCR document integrity and confidentiality must be provided while conforming to regulations or other security, confidentiality, or privacy protections as applicable within the scope of this specification.
1.4.1 Conditions of security and privacy for a CCR instance must be established in a way that allows only properly authenticated and authorized access to the CCR document instance or its elements. The CCR document instance must be self-protecting when possible, and carry sufficient data embedded in the document instance to permit access decisions to be made based upon confidentiality constraints or limitations specific to that instance.
1.4.2 Additional Subcommittee E31.20 on Security and Privacy guides, practices, and specifications will be published in support of the security and privacy needs of specific CCR use cases. When a specification is necessary to assure interoperability or other required functionality, the CCR core schema will be extended to meet the profile requirements of the underlying use case, building upon existing standards and specifications whenever possible.
1.4.2.1 For profiles that require digital signatures, W3C’s XML digital signature standard (http://www.w3.org/TR/xmldsig-core) will be used with digital certificates. Encryption will be provided using W3C’s XML encryption standard (http://www.w3.org/TR/xmlenc-core).
1.5 The CCR is an outgrowth of the Patient Care Referral Form (PCRF) designed and mandated by the Massachusetts Department of Public Health for use primarily in inpatient settings.
1.6 It is assumed that information contained in a CCR will be confirmed as appropriate in clinical practice. For example, the CCR insurance fields should not be construed to address all reimbursement, authorization, or eligibility issues, and current medications and other critical data should be validated.
1.7 Committee E31 gratefully acknowledges the Massachusetts Medical Society, HIMSS (Health Information Management and Systems Society), the American Academy of Family Physicians, the American Academy of Pediatrics, the American Medical Association, the Patient Safety Institute, the American Health Care Association, the National Association for the Support of Long Term Care, the Mobile Healthcare Alliance (MoHCA), the Medical Group Management Association (MGMA) and the American College of Osteopathic Family Physicians (ACOFP) as co-leaders with ASTM in the standard’s development and adoption, and joins them in inviting the collaboration of all stakeholders, including other clinical specialty societies, other professional organizations, insurers, vendors, other healthcare institutions, departments of public health, and other government agencies.
