This page is part of the C-CDA on FHIR Implementation Guide (v1.2.0: STU 1) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.
CCDA on FHIR Client |
This describes the expected capabilities of the C-CDA on FHIR Document Consumer (aka client) actor which is responsible for creating and initiating the queries for clinical documents provided by a C-CDA on FHIR Document Source (aka server) actors. This CapabilityStatement imports and extends the us-core-client CapabilityStatement |
CCDA on FHIR Server |
This describes the expected capabilities of the C-CDA on FHIR Document Source (aka server) actor which is responsible for responding to the queries for clinical documents provided by a C-CDA on FHIR Document Consumer (aka client) actor. This CapabilityStatement imports and extends the us-core-server CapabilityStatement |
These are profiles on resources or data types that describe patterns used by other profiles, but cannot be instantiated directly. I.e. instances can conform to profiles based on these abstract profiles, but do not declare conformance to the abstract profiles themselves.
US Realm Header |
This profile defines constraints that represent common administrative and demographic concepts for US Realm clinical documents. Further specification, such as type, are provided in document profiles that conform to this profile. |
These define constraints on FHIR resources for systems conforming to this implementation guide.
Care Plan Document |
CARE PLAN FRAMEWORK: A Care Plan (including Home Health Plan of Care (HHPoC)) is a consensus-driven dynamic plan that represents a patient and Care Team Members prioritized concerns, goals, and planned interventions. It serves as a blueprint shared by all Care Team Members (including the patient, their caregivers and providers), to guide the patients care. A Care Plan integrates multiple interventions proposed by multiple providers and disciplines for multiple conditions. A Care Plan represents one or more Plan(s) of Care and serves to reconcile and resolve conflicts between the various Plans of Care developed for a specific patient by different providers. While both a plan of care and a care plan include the patient’s life goals and require Care Team Members (including patients) to prioritize goals and interventions, the reconciliation process becomes more complex as the number of plans of care increases. The Care Plan also serves to enable longitudinal coordination of care. The Care Plan represents an instance of this dynamic Care Plan at a point in time. The composition itself is NOT dynamic. Key differentiators between a Care Plan profile and CCD profile (another snapshot in time document):
|
Consultation Note |
The Consultation Note is generated by a request from a clinician for an opinion or advice from another clinician. Consultations may involve face-to-face time with the patient or may fall under the auspices of telemedicine visits. Consultations may occur while the patient is inpatient or ambulatory. The Consultation Note should also be used to summarize an Emergency Room or Urgent Care encounter. A Consultation Note includes the reason for the referral, history of present illness, physical examination, and decision-making components (Assessment and Plan). |
Continuity of Care Document |
This profile was originally based on the Continuity of Care Document (CCD) Release 1.1 which itself was derived from HITSP C32 and CCD Release 1.0. The Continuity of Care Document (CCD) profile represents 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 to support the continuity of care. The primary use case for the CCD is to provide a snapshot in time containing the germane clinical, demographic, and administrative data for a specific patient. The key characteristic of a CCD is that the Composition.event.code is constrained to “PCPR”. This means it does not function to report new services associated with performing care. It reports on care that has already been provided. The CCD provides a historical tally of the care over a range of time and is not a record of new services delivered. More specific use cases, such as a Discharge Summary, Transfer Summary, Referral Note, Consultation Note, or Progress Note, are available as alternative profiles. |
Diagnostic Imaging Report |
A Diagnostic Imaging Report (DIR) is a document that contains a consulting specialist’s interpretation of image data. It conveys the interpretation to the referring (ordering) physician and becomes part of the patient’s medical record. It is for use in Radiology, Endoscopy, Cardiology, and other imaging specialties. Note: this document type overlaps with the FHIR DiagnosticReport resource. Most use cases will want to use the specific resource type, but this document type is still useful for CDA to FHIR conversion and other such use cases. |
Discharge Summary |
The Discharge Summary is a document which synopsizes a patient’s admission to a hospital, LTPAC provider, or other setting. It provides information for the continuation of care following discharge. The Joint Commission requires the following information to be included in the Discharge Summary (http://www.jointcommission.org/): The reason for hospitalization (the admission) The procedures performed, as applicable The care, treatment, and services provided The patients condition and disposition at discharge Information provided to the patient and family Provisions for follow-up care The best practice for a Discharge Summary is to include the discharge disposition in the display of the header. |
History and Physical |
A History and Physical (H&P) note is a medical report that documents the current and past conditions of the patient. It contains essential information that helps determine an individual’s health status. The first portion of the report is a current collection of organized information unique to an individual. This is typically supplied by the patient or the caregiver, concerning the current medical problem or the reason for the patient encounter. This information is followed by a description of any past or ongoing medical issues, including current medications and allergies. Information is also obtained about the patient’s lifestyle, habits, and diseases among family members. The next portion of the report contains information obtained by physically examining the patient and gathering diagnostic information in the form of laboratory tests, imaging, or other diagnostic procedures. The report ends with the clinician’s assessment of the patient’s situation and the intended plan to address those issues. A History and Physical Examination is required upon hospital admission as well as before operative procedures. An initial evaluation in an ambulatory setting is often documented in the form of an H&P note. |
Operative Note |
The Operative Note is a frequently used type of procedure note with specific requirements set forth by regulatory agencies. The Operative Note is created immediately following a surgical or other high-risk procedure. It records the pre- and post-surgical diagnosis, pertinent events of the procedure, as well as the condition of the patient following the procedure. The report should be sufficiently detailed to support the diagnoses, justify the treatment, document the course of the procedure, and provide continuity of care. |
Procedure Note |
A Procedure Note encompasses many types of non-operative procedures including interventional cardiology, gastrointestinal endoscopy, osteopathic manipulation, and many other specialty fields. Procedure Notes are differentiated from Operative Notes because they do not involve incision or excision as the primary act. The Procedure Note is created immediately following a non-operative procedure. It records the indications for the procedure and, when applicable, postprocedure diagnosis, pertinent events of the procedure, and the patients tolerance for the procedure. It should be detailed enough to justify the procedure, describe the course of the procedure, and provide continuity of care. |
Progress Note |
This profile represents a patient’s clinical status during a hospitalization, outpatient visit, treatment with a LTPAC provider, or other healthcare encounter. Taber’s medical dictionary defines a Progress Note as An ongoing record of a patient’s illness and treatment. Physicians, nurses, consultants, and therapists record their notes concerning the progress or lack of progress made by the patient between the time of the previous note and the most recent note. Mosby’s medical dictionary defines a Progress Note as Notes made by a nurse, physician, social worker, physical therapist, and other health care professionals that describe the patient’s condition and the treatment given or planned. A Progress Note is not a re-evaluation note. A Progress Note is not intended to be a Progress Report for Medicare. Medicare B Section 1833(e) defines the requirements of a Medicare Progress Report. |
Referral Note |
A Referral Note communicates pertinent information from a provider who is requesting services of another provider of clinical or non-clinical services. The information in this document includes the reason for the referral and additional information that would augment decision making and care delivery. Examples of referral situations are:
|
Transfer Summary |
This profile describes constraints for a Transfer Summary. The Transfer Summary standardizes critical information for exchange of information between providers of care when a patient moves between health care settings. Standardization of information used in this form will promote interoperability; create information suitable for reuse in quality measurement, public health, research, and for reimbursement. |
These define constraints on FHIR data types for systems conforming to this implementation guide.
Authorization Extension |
The C-CDA on FHIR Authorization Extension contains the C-CDA on FHIR Consent profile which represents information about a patient’s consents. |
Data Enterer Extension |
The Data Enterer Extension represents the person who transferred the content, written or dictated, into the clinical document. To clarify, an author provides the content, subject to their own interpretation; a dataEnterer adds an author’s information to the electronic system. For further information see the C-CDA specification here: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=408. |
Informant Extension |
The C-CDA on FHIR Informant Extension describes an information source for any content within the clinical document. This informant is constrained for use when the source of information is an assigned health care provider for the patient. |
Information Recipient Extension |
The Information Recipient Extension records the intended recipient of the information at the time the document was created. For further information see the C-CDA specification here: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=408. |
Order Extension |
The Order Extension represents orders that are fulfilled by this document such as a radiologists report of an x-ray. |
Participant Extension |
The C-CDA on FHIR Participant Extension identifies supporting entities, including parents, relatives, caregivers, insurance policyholders, guarantors, and others related in some way to the patient. A supporting person or organization is an individual or an organization with a relationship to the patient. A supporting person who is playing multiple roles would be recorded in multiple participants (e.g., emergency contact and next-of-kin). |
Performer Extension |
The Performer Extension represents clinicians who actually and principally carry out the clinical services being documented. In a transfer of care this represents the healthcare providers involved in the current or pertinent historical care of the patient. Preferably, the patients key healthcare care team members would be listed, particularly their primary physician and any active consulting physicians, therapists, and counselors. |
Version Number |
The CCDA on FHIR VersionNumber Extension represents a numeric value used to version successive replacement documents. For further information see the C-CDA specification here: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=408. |
These define sets of codes used by systems conforming to this implementation guide.
Care Plan Document Type |
Care Plan Document Type |
ConsultDocumentType |
ConsultDocumentType |
DischargeSummaryDocumentTypeCode |
DischargeSummaryDocumentTypeCode |
HPDocumentType |
HPDocumentType |
LOINC Imaging Document Codes |
LOINC Imaging Document Codes |
ProcedureNoteDocumentTypeCodes |
ProcedureNoteDocumentTypeCodes |
ProgressNoteDocumentTypeCode |
ProgressNoteDocumentTypeCode |
ReferralDocumentType |
ReferralDocumentType |
SurgicalOperationNoteDocumentTypeCode |
SurgicalOperationNoteDocumentTypeCode |
TransferDocumentType |
TransferDocumentType |
These define transformations to convert between codes by systems conforming with this implementation guide.
C-CDA Immunization Refusal to FHIR Immunization Status Reason |
C-CDA Immunization Refusal to FHIR Immunization Status Reason |
C-CDA NullFlavor to FHIR Data Absent Reason |
C-CDA NullFlavor to FHIR Data Absent Reason. Adapted from https://hl7.org/fhir/R4/cm-data-absent-reason-v3.html but several key changes have been made. Note that this prior concept map (from R4) is no longer included in current FHIR build. |
C-CDA Problem Status value to FHIR Condition clinicalStatus |
C-CDA Problem Status value to FHIR Condition clinicalStatus |
C-CDA Severity to FHIR Severity |
C-CDA Severity to FHIR Severity |
C-CDA section to FHIR Condition category code |
C-CDA section code to FHIR Condition category |
C-CDA to FHIR Address Use |
C-CDA to FHIR Address Use |
C-CDA to FHIR Adminmistrative Gender |
C-CDA to FHIR Adminmistrative Gender |
C-CDA to FHIR Allergy Status |
C-CDA to FHIR Allergy Status |
C-CDA to FHIR Immunization Status |
C-CDA to FHIR Immunization Status |
C-CDA to FHIR Medication Status |
C-CDA to FHIR Medication Status. Based on http://cdasearch.hl7.org/examples/view/Medications/Medication%20statusCodes |
C-CDA to FHIR NameUse |
C-CDA to FHIR NameUse |
C-CDA to FHIR No Known Allergies |
C-CDA Allergy Intolerance Observation value to FHIR code for No Known Allergies |
C-CDA to FHIR Procedure Status |
C-CDA to FHIR Procedure Status |
C-CDA to FHIR Telecom Type |
C-CDA to FHIR Telecom Type. In CDA, these are prefixes inside the value attribute. |
C-CDA to FHIR Telecom Use |
C-CDA to FHIR Telecom Use |
CCDA Criticality to FHIR Criticality |
C-CDA Criticality to FHIR Criticality |
CCDA Medication Activity Mood to FHIR MedicationRequest.intent |
CCDA Medication Activity Mood to FHIR MedicationRequest.intent |
CCDA Problem Concern Status to FHIR Condition Clinical Status |
CCDA Problem Concern Status to FHIR Condition Clinical Status |
CCDA to FHIR Allergy Intolerance Category |
C-CDA Allergy Intolerance Observation value elements to FHIR category codes |
CCDA to FHIR Allergy Intolerance Type |
C-CDA Allergy Intolerance Observation value elements to FHIR type codes |
FHIR Allergy Intolerance Type to CCDA value |
FHIR type codes to C-CDA Allergy Intolerance Observation value |
FHIR Condition category to C-CDA section code |
FHIR Condition category to C-CDA section code |
FHIR Condition clinicalStatus to C-CDA Problem Status value |
FHIR Condition clinicalStatus to C-CDA Problem Status value |
FHIR Criticality to C-CDA Criticality |
FHIR Criticality to C-CDA Criticality |
FHIR Data Absent Reason to C-CDA NullFlavor |
FHIR Data Absent Reason to C-CDA NullFlavor. Adapted from https://hl7.org/fhir/R4/cm-data-absent-reason-v3.html but several key changes have been made. Note that this prior concept map (from R4) is no longer included in current FHIR build. |
FHIR Immunization Site to C-CDA Immunization approachSiteCode |
FHIR Immunization Site to C-CDA Immunization approachSiteCode. Note that the FHIR valueset is example and may be incomplete (only 2 codes) |
FHIR Immunization Status Reason to C-CDA Immunization Refusal |
FHIR Immunization Status Reason to C-CDA Immunization Refusal |
FHIR Severity to C-CDA Severity |
FHIR Severity to C-CDA Severity |
FHIR to C-CDA Address Use |
FHIR to C-CDA Address Use. Based on http://hl7.org/fhir/cm-address-use-v3.html |
FHIR to C-CDA Adminmistrative Gender |
FHIR to C-CDA Adminmistrative Gender. Based on http://hl7.org/fhir/cm-administrative-gender-v3.html |
FHIR to C-CDA Allergy Status |
FHIR to C-CDA Allergy Status |
FHIR to C-CDA Immunization Status |
FHIR to C-CDA Immunization Status |
FHIR to C-CDA Medication Status |
FHIR to C-CDA Medication Status. Based on http://cdasearch.hl7.org/examples/view/Medications/Medication%20statusCodes |
FHIR to C-CDA NameUse |
FHIR to C-CDA NameUse. Based on http://hl7.org/fhir/cm-name-use-v3.html |
FHIR to C-CDA No Known Allergies |
FHIR negated code for No Known Allergies to C-CDA Allergy Intolerance Observation value. Note that when placing the target code in the C-CDA AllergyIntolerance Observation, the Observation must have @negationInd=true. |
FHIR to C-CDA Procedure Status |
FHIR to C-CDA Procedure Status |
FHIR to C-CDA Telecom Type |
FHIR to C-CDA Telecom Type. In CDA, these are prefixes inside the value attribute. |
FHIR to C-CDA Telecom Use |
FHIR to C-CDA Telecom Use. Note that CDA’s PG use code is equivalent to FHIR’s ContactPoint.system of ‘pager’. |
FHIR to CCDA Allergy Intolerance Category |
FHIR AllergyIntolerance category code to C-CDA Allergy Intolerance Observation value |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
These are resources that are used within this implementation guide that do not fit into one of the other categories.
CF-allergy |
ccda-to-fhir-allergy |
CF-immunization |
ccda-to-fhir-immunization |
CF-medication |
ccda-to-fhir-medication |
CF-patient |
ccda-to-fhir-patient |
CF-problem |
ccda-to-fhir-problem |
CF-procedure |
ccda-to-fhir-procedure |
FC-allergy |
fhir-to-ccda-allergy |
FC-immunization |
fhir-to-ccda-immunization |
FC-medication |
fhir-to-ccda-medication |
FC-problem |
fhir-to-ccda-problem |