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
