Home > HealthCare IT > Overview Of HITSP/ CDA /CCD in Healthcare IT

Overview Of HITSP/ CDA /CCD in Healthcare IT

This is just overview of HITSP.

To know more about in detail comment on this or contact me for any help or guidance.

Overview of Tutorial

  • Why HITSP for CCHIT Certification?
  • What is HITSP?
  • What HITSP Does?
  • What are CCD, CDA and CCR?
  • What is templateId?
  • Sample problem section from CCD document
  • How to read/write HITSP document in EHR?
  • From where CCHIT validate HITSP Document?

Why HITSP C83?

  • From Patient’s Perspective
  1. In many environments much of the patient record is still captured in an unstructured format that is encapsulated within an image file or as unstructured text in an electronic file such as a word processing or Portable Document Format (PDF) documents.
  2. There is a need to raise the level of interoperability for these documents to provide full access to the longitudinal patient record across a continuum of care.
  • From doctors & EHR Provider’s Perspective
  1. Each and every EHR system has its own format to process the data
  2. One EHR system does not know the data retrieve from other EHR system
  3. The American Relief and Recovery Act of 2009 (ARRA)
  • provides more than $30 billion for Health IT (HIT) investments
  • EHR Providers with qualifying EHRs can receive incentive payments through Medicare or Medicaid as early as 2011
  • Medicare reimbursement penalties for those who are not meaningful EHR users begin in FY2016

What is HITSP?

HITSP In American Health Information Community

  • As seen in the above figure It’s a part of American Health Information Community

American Health Information Community

  • a federal advisory body chartered in 2005, made up of leaders from public and private health sectors, was formed to make recommendations to the Secretary of the U.S. Department of Health and Human Services
  1. identify Interoperability Standards to facilitate the exchange of patient data (HITSP)
  2. define a process for certifying that health IT products comply with appropriate standards through the Certification Commission for Healthcare Information Technology (CCHIT)
  3. develop a series of prototypes to establish the requirements of a Nationwide Health Information Network (NHIN)
  4. address the privacy and security challenges presented by electronic health information exchange through multi-state collaboration(HISPC)
  • Health Insurance Portability and Accountability Act (HIPAA)

What HITSP Does?

  • It provides Interoperability Specification which provides unambiguous instructions for how two or more systems should exchange information within the specific context of the Use Case
  • The purpose of the HITSP is to define the Content Modules for document based on CCD constructs utilizing clinical information

–      Clinical Care Document (CCD) builds upon the Clinical Document Architecture (CDA) and Clinical Care Record (CCR) specification


  • Clinical Document Architecture
  1. ANSI/HL7 R1-2000, R2-2005
  • E-Documents for Interoperability
  1. Key component for local, regional, national electronic health records
  2. Gentle on-ramp to information exchange
  3. Everyone uses documents
  4. EMR compatible, no EMR required
  5. All types of clinical documents


  • Standard Specification for Continuity of Care Record (CCR)
  • 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.
  • Released fall, 2005


HL7 v/s ASTM

  • Conflicting?
  • Overlapping?
  • What if you could have both?
    • What if you could have your data elements?
    • And send them in a common exchange framework?


HL7 and ASTM co-ordinate

  • CDA is designed to support professional society recommendations, national clinical practice guidelines, standardized data sets, etc.
  • From the perspective of CDA, the ASTM CCR is a standardized data set that can be used to constrain CDA specifically for summary documents.
  • The resulting specification, known as the Continuity of Care Document (CCD), is being developed as a collaborative effort between ASTM and HL7.

HITSP List of Standards

  • C28 – Emergency Care Summary Document
  • C32 – Summary Documents Using CCD
  • C35 – Lab Result Terminology
  • C38 – Patient Level Quality Data Document
  • C72 – Immunization Message
  • C78 – Immunization Document
  • C83 – All standards are merged in this

HITSP Clinical Document Components

HITSP different standards

Module Category Description
Personal Information The personal information includes name, address, contact information, personal identification information, ethnic and racial affiliation and marital status of a person
Support Support includes the patient’s sources of support, such as immediate family, relatives and/or guardians. This includes next of kin, caregivers, support organizations, and key contacts relative to healthcare decisions. Support providers may include providers of healthcare related services, such as a personally controlled health record, or registry of emergency contacts
Healthcare Providers This includes a list of the healthcare providers and organizations that provide or have provided care to the patient
Insurance Providers and Payers Insurance providers include data about the organizations or individuals who may pay for a patient’s healthcare, and the relationships, demographics and identifiers of those individuals with respect to the payer. Such organizations or individuals may be health insurance plans, other payers, guarantors, parties with financial responsibility, some combination of payers or the patient directly
Allergies and Drug Sensitivities This includes the allergy or intolerance conditions, severity and associated adverse reactions suffered by the patient
Conditions This includes relevant clinical problems and conditions for which the patient is receiving care, including information about onset, severity, and providers treating the condition. Conditions are broader than, but include diagnoses
Medications This includes the patient’s prescription or non-prescription medications and medication history, and may include prescriptions, fulfillments and medication administration activities
Immunizations This includes data describing the patient’s immunization history
Vital Signs This includes data about the patient’s vital signs
Test Results This includes data about current and historical test results from laboratory or other diagnostic testing performed on the patient
Encounter This includes data describing the interactions between the patient and clinicians. Interaction includes both in-person and non-in-person encounters such as telephone and email
Procedures This includes data describing procedures performed on a patient
Family History Data defining the patient’s genetic relatives in terms of possible or relevant health risk factors that have a potential impact on the patient’s health
Social History Data defining the patient’s occupational, personal (e.g. lifestyle), social, and environmental history that have a potential impact on the patient’s health
Medical Equipment Medical Equipment includes implanted and external medical devices and equipment that a patient’s health status depends on, as well as any pertinent equipment or device history
Functional Status Data defining the patient’s functional status with respect to, ambulatory ability, mental status or competency, activities of daily living, including bathing, dressing, feeding, grooming, home/living situation having an effect on the health status of the patient, and ability to care for self
Plan of Care The plan of care contains data defining prospective or intended orders, interventions, encounters, services, and procedures for the patient

EXAMPLE ARTIFACT: Vaccine and Drug Administration and Reporting Information Exchanges

Information Exchange sample

What is templateID and Sample Problem Section

CDA Template Modeling

  • Constraints are modeled using UML properties and directed associations in conjunction with stereotypes from the CDA Profile
  • Types of constraints:
  1. Property constraints
  • Used to specify fixed or default value
  • Used to restrict cardinality and/or data type
  1. Vocabulary constraints on coded attributes
  • Used to restrict code, codeSystem, etc.
  • Template-related constraints
  1. Template id
  2. Template relationships (is-a, has-a)

CCD Problem Section

  • CCD SHOULD contain exactly one and SHALL NOT contain more than one Problem section(templateId 2.16.840.1.113883.
  • The Problem section SHALL contain a narrative block, and SHOULD contain clinical statements.
  • Clinical statements SHOULD include one or more problem acts (templateId 2.16.840.1.113883.
  • A problem act SHOULD include one or more problem observations (templateId 2.16.840.1.113883.

Modeling the Conformance Rule

  1. Create classes that extend the CDA model (one for each template):
    1. ContinuityOfCareDocument (extends cda::ClinicalDocument)
    2. ProblemSection (extends cda::Section)
    3. ProblemAct (extends cda::Act)
    4. ProblemObservation (extends cda::Observation)
  2. Apply stereotypes from CDA profile to classes:
    1. <<cdaTemplate>> stereotype is applied to all classes
    2. templateId stereotype property value is specified
  3. Create directed associations between classes:
    1. ContinuityOfCareDocument -> ProblemSection
    2. ProblemSection -> ProblemAct
    3. ProblemAct -> ProblemObservation
    4. Multiplicity (upper bound) of the association may be specified to indicate exactly one or more than one

CDA Template Model for CCD Problem Section

CCD problem section

Generated constraints

  • ContinuityOfCareDocument_templateId:

–      self.hasTemplateId(‘2.16.840.1.113883.10.20.1’)

  • ContinuityOfCareDocument_problemSection:

–      self.getSection()->one(sect : cda::Section | sect.oclIsKindOf  (ccd::ProblemSection))

  • ProblemSection_templateId:

–      self.hasTemplateId(‘2.16.840.1.113883.’)

  • ProblemSection_problemAct:

–      self.getAct()->exists(act : cda::Act | act.oclIsKindOf(ccd::ProblemAct))

  • ProblemAct_templateId:

–      self.hasTemplateId(‘2.16.840.1.113883.’)

  • ProblemAct_problemObservation:

–      self.getObservation(obs : cda::Observation | obs.oclIsKindOf(ccd::ProblemObservation))

  • ProblemObservation_templateId:

–      self.hasTemplateId(‘2.16.840.1.113883.’)

How To Read/Write HITSP document in EHR?

XML serialization

  • Each HITSP document is an XML document.
  • To read/write xml document we have to use xml serialization and deserialization
  • To validate the XML file there is one XML schema file called XSD
  • To generate valid HITSP schema file first we need to get compatible XSD file

How to create XSD file for HITSP?

  • There is one testing tool site called http://Xreg2.nist.gov
  • NIST in collaboration with Alschuler Associates, LLC, Integrating the Healthcare Enterprise (IHE) and the CCHIT Health IT Collaboration Effort “LAIKA“ have maintain this site
  • In the validation tool we can check our xml file for developer and implementer point of view
  • In the download section of the site we get the latest version of HITSP with samples
  • There is multiple XSD file for HITSP with the help of this we have to create one XSD file
  • There is one software called XSD.exe freely provided by Microsoft to generate class for XSD
  • Now with the help of that class in C# or VB.NET we can use that class in our application with xml serializes and de serialize.

Validate the HITSP C83 Document

  • To get the certification US government created the CCHIT
  • CCHIT uses Laika for only the CCHIT Certified® 2011 certification programs at the present time
  • Laika is an open source testing framework
  • For CCHIT Certified® 2011 certification programs, testing involves validation of a file to the HITSP C32 patient summary specification

How Laika Validate?

  • Actors
  • Proctor: conducts clinical inspection and oversees the clinical, security and interoperability portions of an inspection.
  • Technical proctor: sets up and conducts interoperability tests

–      Steps below are performed by technical proctor unless otherwise noted.

CCHIT Testing with Laika

  • CCHIT breaks interoperability testing into two tests

–      Display and File (Read our document )

  • We have to give our xml document and txt file for test patient and they will upload it and validate it in Laika

–      Generate and Format (Write our document)

  • They will check our uploaded xml document for display in Laika

Note:- I have created this blog post from reading all related material from internet and HL7, HITSP and IHE

Reference Material for HITSP, CCD, CDA, HL7.

1) https://mdht.projects.openhealthtools.org/files/documents/58/217/CDA_Tools_Overview_HL7.ppt

Author: John T.E Timm (IBM) and Dave Carlson (VA)

2) CCD quick start tutorial by HIMSS

Categories: HealthCare IT
  1. Anil Goswami
    July 6, 2010 at 12:51 pm

    Its a nice blog. Important information gathering from various sources specially of CCD and HITSP is like make an research paper with good hard work. thanks for providing such information. Thanks.

  2. August 16, 2010 at 5:24 pm

    A very helpful blog–it will be a good reference. A question: Is there a document that defines exactly what a CCD must contain? For instance, you quote in the blog post, “CCD SHOULD contain exactly one and SHALL NOT contain more than one Problem section(templateId 2.16.840.1.113883.”. Where does one find these authoritative rules?

    • August 17, 2010 at 6:26 am

      Hi Joe,

      You can read the CCD quick start tutorial by HIMSS. i have attached it in reference material.

  3. Tim Henke
    November 12, 2010 at 7:39 pm


    I was wondering if you could send me the single XSD file you are using for validating? I’m having a difficult time condensing the XSD files provided in the HITSP examples into one file. If not that then some hints on exactly how to combine these into a sigle file would be greatly appreicated.



  4. Santhosh
    January 12, 2011 at 6:39 pm

    Hi Nishant,
    Would it be possible for you to post a sample C32 conformant CCD example that fulfills meaningful use criteria?

    • January 12, 2011 at 6:53 pm

      Hi Santosh,

      I cant provide you that. however i can provide you any guidance to achieve meaningful use complaint C32 file.

      • Santhosh
        January 16, 2011 at 6:46 pm

        One of the most simple & confusing part of CCD is usage of ID element. As I know ID element consists of root & extension attribute.
        What should be the values for root & extension attribute in recordTarget , assignedEntity, representedOrganization and within sections ( in Entry elements etc)

      • January 18, 2011 at 2:52 pm


        In any section of CCD there is ID element which uniquely identify that section information.

        As you have written for record target as record target contains patient information so in that section’s ID you can pass your EMR system’s patient-id or SSN or License-ID. however for security reasons we should not pass patient’s personal information like SSN and License. so patient ID is right value.

        as for representedOrganization you can pass unique id which identify that doctor clinic like that.

        hope this is helpful

      • Santhosh
        January 19, 2011 at 6:10 pm


        So extension attribute would contain patient id?
        What about the value for root attribute(generally what should be its value in other section as well. Can we use our organization’s OID for root attribute? )

  5. Santhosh
    January 19, 2011 at 6:12 pm

    My example got trimmed due to HTML encoding.Trying post it here again

    &ltrecordTarget typeCode=”RCT” contextControlCode=”OP”>
    &ltpatientRole classCode=”PAT”>
    &ltid root=”???” extension=”Patient-ID-In EMR”/>

    • January 20, 2011 at 8:27 am

      Yes you can pass your organization OID as Root and in extension you can pass anything which identify that root. so for organization OID as root and “Organization-Id” as extention.

      • Santhosh
        January 21, 2011 at 10:12 am

        Hi Nishant,

        Sorry for bothering you with repeated questions on the same item.Hope these are my last questions on <id> element.
        I have two questions :

        1. I am using our EMR organzation’s OID in root element for patientRole,providerOrganization,assignedAuthor,representedOrganization,assignedEntity etc.Is this correct? Because I have noticed in some CCD files that root values are different across above mentioned elements in the same document.

        2. As you have mentioned in your previous reply, I am passing database row identifier for above mentioned elements(patientRole,providerOrganization etc)

        <patientRole classCode=”PAT”>
        <id root=”2.16.840.1.113883.3.011″ extension=”2318926″/> [ extention value is Patient ID in EMR/database ]

        <id root=”2.16.840.1.113883.3.011″ extension=”2351″/> [ extention value is doctor’s clinic ID in EMR ]

        <id root=”2.16.840.1.113883.3.011″ extension=”45243″/> [ extention value is doctor/provider’s ID in EMR ]

        <representedOrganization classCode=”ORG” determinerCode=”INSTANCE”>
        <id root=”2.16.840.1.113883.3.011″ extension=”2351″/> [ extention value is doctor/’s clinic ID in EMR ]

        <representedCustodianOrganization classCode=”ORG” determinerCode=”INSTANCE”>
        <id root=”2.16.840.1.113883.3.011″ extension=”2351″/> [ extention value is doctor’s clinic ID in EMR ]

        <id root=”2.16.840.1.113883.3.011″ extension=”45243″/> [ extention value is doctor/provider’s ID in EMR ]

        3. Please advise what should be the id & extention values for below mentioned section :

        <!–Problem section–>
        <act classCode=”ACT” moodCode=”EVN”>
        <templateId root=”2.16.840.1.113883.″ assigningAuthorityName=”CCD Problem Act”/>
        <templateId root=”2.16.840.1.113883.″ assigningAuthorityName=”HITSP Condition”/>
        <templateId root=”″ assigningAuthorityName=”IHE Concern Entry”/>
        <templateId root=”″ assigningAuthorityName=”IHE Problem Concern Entry”/>
        <id root=”” extension=””/>

        <!–Medication section–>
        <substanceAdministration classCode=”SBADM” moodCode=”EVN”>
        <templateId root=”2.16.840.1.113883.″ assigningAuthorityName=”CCD”/>
        <templateId root=”2.16.840.1.113883.″ assigningAuthorityName=”HITSP C83″/>
        <templateId root=”″ assigningAuthorityName=”IHE PCC”/>
        <templateId root=”″ assigningAuthorityName=”IHE PCC”/>
        <id root=”” extension=””/>

        <!–Lab result section–>
        <organizer classCode=”BATTERY” moodCode=”EVN”>
        <templateId root=”2.16.840.1.113883.″/>
        <!–Result organizer template–>
        <id root=”” extension=””/>

        I really appreciate your help.

        Thank You,

      • January 22, 2011 at 7:46 am

        Hi Santosh,

        You completely miss interpreted my last comment.

        i had told you that in every sections of CCD there is ID element.

        and in that section you can pass that sections root element you can pass primary key of your database and extension column name of that related table.

        So for example,

        patient record target

        root = ‘hkhf6287361hfkjdsf768734’
        extension = ‘Patient-Id’


        root = ‘fjhgkjf6587436fdfdg’
        extention = ‘Organization-id’


        root= ‘fhfkjdsfhsfkjdsh68763’
        extention = ‘problem-Id’

        Hope now it is clear to you.

      • Santhosh
        January 24, 2011 at 10:49 pm

        I followed your instruction and made changes as follows :
        <patientRole classCode=”PAT”>
        <id root=”f2ee9a6c-4550-4eb3-bdcc-26e93f6be6a5″ extension=”PatientID”/>

        <streetAddressLine>Dummy street</streetAddressLine>


        But after applying XSL, the file looks like this :


        Note that text “patientID” is dislayed next to MRN. I believe its suppose to display the patient’s unique id in database

      • January 25, 2011 at 5:34 am

        Hi Santosh,

        For recordTarget there is error in XSL file.

        CCD is the patient summary document and follows CDA (Clinical Document Architecture).

        CDA is part of HL7 RIM model.

        RIM model has its structure and basic datatypes collection.

        So, ID, TemplateId, Code,Entry, observation have their own format and value.

        and we are discussing about ID which has datatype II in XSD is a basic datatype of RIM model.

        II class is used as unique identifier with root represent as your unique id and extension is description.

        So for only recordtarget property you can pass SSN or Unique Id as Extension and root your 36 char unique identifier of your database.

        I have done the same.

        hope this helps.

      • Santhosh
        February 4, 2011 at 7:15 am

        Hi Nishant,

        Sorry for the delayed response.Thank you very much for clearing my doubts with CCD.
        Your feedback helped me to come out with valid CCD file.

        Thank You Once again !


  6. Vivette Reolada
    April 11, 2011 at 8:20 pm


    I am wondering if you can help provide some clarification on Problem entry regarding the ID that contain root and extension for identifiers. The problem entry should contain one or more act – 2.16.840.1.113883. and the problem act should contain one or more observation – 2.16.840.1.113883. Both the Problem Act and problem observation contain an ID.
    – which ID should be populated with the root and extension for tracking purpose or for intrinsic identifier on a given problem?
    – is it valid to populate both ID with the same root and extension for tracking purpose or for intrinsic identifier on a given problem?

    12 Test Street - Suite 101
    Auburn, New York 13021

    George T. Test, M.D.

    • April 12, 2011 at 6:12 am

      Hi Vivette,

      below are my comments for your query.

      – which ID should be populated with the root and extension for tracking purpose or for intrinsic identifier on a given problem?
      Ans. For tracking purpose you should pass your problem section table unique identifier from your database in root element and in extension you
      can pass its column name like “ProblemId”.

      – is it valid to populate both ID with the same root and extension for tracking purpose or for intrinsic identifier on a given problem?
      Ans. it is advisable not to use same identifier for the different act or observation, if you have more than one unique identifier in your database query while fetching data like problem Id and ProblemDetail Id then you can use that also.

      Hope this helps.

  7. Vivette Reolada
    April 11, 2011 at 8:58 pm

    trying again to post with the html & xml tags

    <entry typeCode=”COMP”>
    <act classCode=”ACT” moodCode=”EVN”>
    <templateId root=”2.16.840.1.113883.″/>
    <templateId root=”2.16.840.1.113883.″/>
    <templateId root=”″/>
    <templateId root=”″/>
    <id root=”2.16.840.1.113883.″ extension=”36″/>
    <code nullFlavor=”NA”/>
    <statusCode code=”active”/>
    <low value=”20000425″/>
    <entryRelationship typeCode=”SUBJ” inversionInd=”false”>
    <observation classCode=”OBS” moodCode=”EVN”>
    <templateId root=”2.16.840.1.113883.″/>
    <templateId root=”″/>
    <id root=”2.16.840.1.113883.″ extension=”36″/>
    <code code=”55607006″ displayName=”Problem” codeSystem=”2.16.840.1.113883.6.96″ codeSystemName=”SNOMED CT”/>
    <reference value=”#prob-0″/>
    <statusCode code=”completed”/>
    <low value=”20000425″/>
    <value xsi:type=”CD” code=”301181009″ displayName=”Cardiovascular Disease Unspec” codeSystem=”2.16.840.1.113883.6.96″ codeSystemName=”SNOMED CT”/>
    <id root=”2.16.840.1.113883.4.6″ extension=”1234567893″/>
    <addr use=”WP”>
    <streetAddressLine>12 Test Street – Suite 101</streetAddressLine>
    <streetAddressLine>Auburn, New York 13021</streetAddressLine>
    <telecom use=”WP” value=”tel:+1(315)-255-1751″/>
    <name>George T. Test, M.D.</name>
    <entryRelationship typeCode=”REFR”>
    <observation moodCode=”EVN” classCode=”OBS”>
    <templateId root=”2.16.840.1.113883.″/>
    <code displayName=”Status” codeSystemName=”LOINC” code=”33999-4″ codeSystem=”2.16.840.1.113883.6.1″/>
    <statusCode code=”completed”/>
    <value xsi:type=”CE” displayName=”Chronic” codeSystemName=”SNOMED CT” code=”90734009″ codeSystem=”2.16.840.1.113883.6.96″/>

  8. Johnd562
    May 10, 2014 at 5:39 pm

    You really make it seem so easy with your presentation but I find this topic to be really something which I think I would never understand. It seems too complicated and extremely broad for me. I’m looking forward for your next post, I’ll try to get the hang of it! ddkefeceegcd

  9. Johnc386
    May 10, 2014 at 5:40 pm

    It is actually a nice and helpful piece of information. I am happy that you simply shared this helpful information with us. Please stay us informed like this. Thank you for sharing. dbacgbdgekcd

    • May 10, 2014 at 5:55 pm

      Hi john,

      What I had covered here is very broad overview of health care IT and certification of EHR.

  1. August 14, 2010 at 10:42 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: