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
- 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.
- 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
- Each and every EHR system has its own format to process the data
- One EHR system does not know the data retrieve from other EHR system
- 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?
- 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
- identify Interoperability Standards to facilitate the exchange of patient data (HITSP)
- define a process for certifying that health IT products comply with appropriate standards through the Certification Commission for Healthcare Information Technology (CCHIT)
- develop a series of prototypes to establish the requirements of a Nationwide Health Information Network (NHIN)
- 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
HL7’s CDA
- Clinical Document Architecture
- ANSI/HL7 R1-2000, R2-2005
- E-Documents for Interoperability
- Key component for local, regional, national electronic health records
- Gentle on-ramp to information exchange
- Everyone uses documents
- EMR compatible, no EMR required
- All types of clinical documents
ASTM’s CCR
- 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’s CDA V/S ASTM’s CCR
- Conflicting?
- Overlapping?
- What if you could have both?
- What if you could have your data elements?
- And send them in a common exchange framework?
ASTM CCR + HL7 CDA = CCD
- 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
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
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:
- Property constraints
- Used to specify fixed or default value
- Used to restrict cardinality and/or data type
- Vocabulary constraints on coded attributes
- Used to restrict code, codeSystem, etc.
- Template-related constraints
- Template id
- 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.10.20.1.11).
- 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.10.20.1.27).
- A problem act SHOULD include one or more problem observations (templateId 2.16.840.1.113883.10.20.1.28).
Modeling the Conformance Rule
- Create classes that extend the CDA model (one for each template):
- ContinuityOfCareDocument (extends cda::ClinicalDocument)
- ProblemSection (extends cda::Section)
- ProblemAct (extends cda::Act)
- ProblemObservation (extends cda::Observation)
- Apply stereotypes from CDA profile to classes:
- <<cdaTemplate>> stereotype is applied to all classes
- templateId stereotype property value is specified
- Create directed associations between classes:
- ContinuityOfCareDocument -> ProblemSection
- ProblemSection -> ProblemAct
- ProblemAct -> ProblemObservation
- Multiplicity (upper bound) of the association may be specified to indicate exactly one or more than one
CDA Template Model for 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.10.20.1.11’)
- ProblemSection_problemAct:
– self.getAct()->exists(act : cda::Act | act.oclIsKindOf(ccd::ProblemAct))
- ProblemAct_templateId:
– self.hasTemplateId(‘2.16.840.1.113883.10.20.1.27’)
- ProblemAct_problemObservation:
– self.getObservation(obs : cda::Observation | obs.oclIsKindOf(ccd::ProblemObservation))
- ProblemObservation_templateId:
– self.hasTemplateId(‘2.16.840.1.113883.10.20.1.28’)
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)
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.
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.10.20.1.11).”. Where does one find these authoritative rules?
Hi Joe,
You can read the CCD quick start tutorial by HIMSS. i have attached it in reference material.
Hi,
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.
Thanks,
Tim
Hi Nishant,
Would it be possible for you to post a sample C32 conformant CCD example that fulfills meaningful use criteria?
Hi Santosh,
I cant provide you that. however i can provide you any guidance to achieve meaningful use complaint C32 file.
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)
Hi,
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
.
.
.
.
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? )
My example got trimmed due to HTML encoding.Trying post it here again
<recordTarget typeCode=”RCT” contextControlCode=”OP”>
<patientRole classCode=”PAT”>
<id root=”???” extension=”Patient-ID-In EMR”/>
.
.
.
.
</patientRole>
</recordTarget>
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.
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 ]
<providerOrganization>
<id root=”2.16.840.1.113883.3.011″ extension=”2351″/> [ extention value is doctor’s clinic ID in EMR ]
<assignedAuthor>
<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 ]
<assignedEntity>
<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.10.20.1.27″ assigningAuthorityName=”CCD Problem Act”/>
<templateId root=”2.16.840.1.113883.3.88.11.83.7″ assigningAuthorityName=”HITSP Condition”/>
<templateId root=”1.3.6.1.4.1.19376.1.5.3.1.4.5.1″ assigningAuthorityName=”IHE Concern Entry”/>
<templateId root=”1.3.6.1.4.1.19376.1.5.3.1.4.5.2″ assigningAuthorityName=”IHE Problem Concern Entry”/>
<id root=”” extension=””/>
<!–Medication section–>
<substanceAdministration classCode=”SBADM” moodCode=”EVN”>
<templateId root=”2.16.840.1.113883.10.20.1.24″ assigningAuthorityName=”CCD”/>
<templateId root=”2.16.840.1.113883.3.88.11.83.8″ assigningAuthorityName=”HITSP C83″/>
<templateId root=”1.3.6.1.4.1.19376.1.5.3.1.4.7″ assigningAuthorityName=”IHE PCC”/>
<templateId root=”1.3.6.1.4.1.19376.1.5.3.1.4.7.1″ assigningAuthorityName=”IHE PCC”/>
<id root=”” extension=””/>
<!–Lab result section–>
<organizer classCode=”BATTERY” moodCode=”EVN”>
<templateId root=”2.16.840.1.113883.10.20.1.32″/>
<!–Result organizer template–>
<id root=”” extension=””/>
I really appreciate your help.
Thank You,
Santhosh
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’
ProviderOrganization
root = ‘fjhgkjf6587436fdfdg’
extention = ‘Organization-id’
problemsection
root= ‘fhfkjdsfhsfkjdsh68763’
extention = ‘problem-Id’
Hope now it is clear to you.
I followed your instruction and made changes as follows :
<patientRole classCode=”PAT”>
<id root=”f2ee9a6c-4550-4eb3-bdcc-26e93f6be6a5″ extension=”PatientID”/>
<addr>
<streetAddressLine>Dummy street</streetAddressLine>
<city>Dumont</city>
<state>CA</state>
<postalCode>50625</postalCode>
<country>US</country>
</addr>
But after applying XSL, the file looks like this :
http://img189.imageshack.us/img189/4584/ccdtransformed.png
Note that text “patientID” is dislayed next to MRN. I believe its suppose to display the patient’s unique id in database
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.
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 !
-Santhosh
Hi,
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.10.20.1.27 and the problem act should contain one or more observation – 2.16.840.1.113883.10.20.1.28. 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
US
George T. Test, M.D.
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.
trying again to post with the html & xml tags
<entry typeCode=”COMP”>
<act classCode=”ACT” moodCode=”EVN”>
<templateId root=”2.16.840.1.113883.10.20.1.27″/>
<templateId root=”2.16.840.1.113883.3.88.11.83.7″/>
<templateId root=”1.3.6.1.4.1.19376.1.5.3.1.4.5.1″/>
<templateId root=”1.3.6.1.4.1.19376.1.5.3.1.4.5.2″/>
<id root=”2.16.840.1.113883.3.227.10.1″ extension=”36″/>
<code nullFlavor=”NA”/>
<statusCode code=”active”/>
<effectiveTime>
<low value=”20000425″/>
</effectiveTime>
<entryRelationship typeCode=”SUBJ” inversionInd=”false”>
<observation classCode=”OBS” moodCode=”EVN”>
<templateId root=”2.16.840.1.113883.10.20.1.28″/>
<templateId root=”1.3.6.1.4.1.19376.1.5.3.1.4.5″/>
<id root=”2.16.840.1.113883.3.227.10.1″ extension=”36″/>
<code code=”55607006″ displayName=”Problem” codeSystem=”2.16.840.1.113883.6.96″ codeSystemName=”SNOMED CT”/>
<text>
<reference value=”#prob-0″/>
</text>
<statusCode code=”completed”/>
<effectiveTime>
<low value=”20000425″/>
</effectiveTime>
<value xsi:type=”CD” code=”301181009″ displayName=”Cardiovascular Disease Unspec” codeSystem=”2.16.840.1.113883.6.96″ codeSystemName=”SNOMED CT”/>
<informant>
<assignedEntity>
<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>
<country>US</country>
</addr>
<telecom use=”WP” value=”tel:+1(315)-255-1751″/>
<assignedPerson>
<name>George T. Test, M.D.</name>
</assignedPerson>
</assignedEntity>
</informant>
<entryRelationship typeCode=”REFR”>
<observation moodCode=”EVN” classCode=”OBS”>
<templateId root=”2.16.840.1.113883.10.20.1.50″/>
<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″/>
</observation>
</entryRelationship>
</observation>
</entryRelationship>
</act>
</entry>
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
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
Hi john,
What I had covered here is very broad overview of health care IT and certification of EHR.