Phillip Burgher, Director of Integration Services at Wellcentive provides an in-depth breakdown of the strengths and weaknesses of healthcare data formats.
For better or worse, healthcare IT vendors have to accommodate a variety of standard formats to send clients’ data from Point A to Point B. In the olden days (aka pre-Meaningful Use), the decision of selecting a preferred format was entirely owned by the vendor. MUStage 1 requirements corralled everyone to adopt the same standard: the Continuity of Care Document (CCD). The CCD is an XML-based standard that marries the best of HL7 technologies to the richness of the clinical data representation provided in a Continuity of Care Record (CCR), without interrupting existing data flows.
Problem solved, right? Not exactly. CCD isn’t specific enough and some fields are optional. The Healthcare Information Technology Standards Panel (HITSP) decided to “further constrain” (read: add more rules) the standard to require certain sections in a specific format within a CCD. Although that’s progress, the specification provided guidance regarding data encoding, but did not require that it be followed.
MU Stage 2, which begins fiscal year 2014 for eligible hospitals/critical access hospitals and calendar year 2014 for eligible professionals, will use the Consolidated-Clinical Document Architecture (C-CDA). CDA is a base standard which provides a common architecture, coding, semantic framework, and markup language for the creation of electronic clinical documents. In general, C-CDA squeezes nine different file types, progress notes, clinical summaries, consult notes, and the CCD into one file, with consistent headers.
Although it reads on paper like the ultimate solution, the standard still requires vendors to understand the intricacies of each file type. As with any standard, there are pros and cons for each format.
| Format | Pro | Con |
| HL7 | Very well established (1987)FamiliarityRelatively extendable – you can add to itBackwards compatible
Handles a wide variety of clinical and administrative data Well defined architecture for when data should be sent – certain events trigger certain message types (e.g., discharge from hospital) |
Designed for hospital settingCan be adapted to meet ambulatory setting needs but uses fields unconventionally |
| X12 | Well established (1982)The HIPAA Transactions and Code Set Rule of 2003 required use of X12 for providers to generate an electronic claim for payersAllows for consistency across claims files | Difficult to read in raw stateSupport very difficultLimited data: procedure codes, insurance, diagnosis code, demographicsIncomplete data. Demographics sometimes missing PCP as billing document might not be PCP.
Varying document types in transit: Provider claim is 835 and Payer returns 837 |
| CCR | Relatively robust data setTheoretically a one-stop shop for sending entire PHM recordGood for historical transfer but incremental updates require sending everything again | Almost no rules for data presentation (e.g., medication name only versus National Drug Code)One-stop shop approach generally includes large files that can bog down transfer. Pathways are generally optimized for either a large number of small files (like HL7) or for large filesPotential for errors increases due to file size |
| CCD | Standard that married the best of HL7 and CCRIncludes content and structureFirst step in formalizing the content that should be sent | Doesn’t require accepted coding systems (NDC, LOINC)Data model for CCD is complexAlthough human readable, involved is a steep learning curve because the structure of CCD is based on CDA, which, in turn, is based on Reference Information Model (RIM); a large, pictorial representation of the HL7 clinical data) |
| C32 | Further constrains the CCD and gives vendors less wiggle roomRequires certain sections even if no data available, you include a placeholder | None – child of CCD |
| CCDA | Attempts to consolidate the various CCD flavors into oneAdds more recommendations for what coding systems to use (not enforced)Changed what sections are required to further constrain data | Recommended coding systems not enforcedRelatively complex to read, but not as difficult as X12Still based on RIMPursuit of objectives within 2 of the 7 MU2 categories involve using Certified EHR Technology that has C-CDA capabilities (Care Coordination & Patient Engagement)
|
| Custom delimited |
Generally very easy to get a report in columnar format out of any systemLow CostQuicker and easier to get data outCustom integrations are less expensive than HL7 or X12 format
Open in Excel -lowers the bar for technical savvy to look at data Easier support Condensed format is good for large data transfer (MB versus GB like CCR)
|
Every custom delimited is a little different so you have to develop functionality to read itNo standard for columns/filesTime required. Higher degree of coordination between vendorsNot quicker to get data transferred to the receiving system
|
All in all, acceptance of industry-wide standardization is improving. The industry is moving toward unified formats and unified content. In theory, the universal nature will decrease the complexity of interoperability and empower groups to meet the ultimate goals of the triple aim: improved patient care and experience at a lower cost.
Phillip Burgher is the Director of Integration Services at Wellcentive, a pioneer in responsible population health management and data analytics for physicians and their organizations where this was first posted
Image credit: bionicteaching via cc
