Question:
How could you represent the ABBI text data using FHIR resources?
Background: We (the FHIR project team) have had some interaction with the ABBI development team in the past week or so. They are looking for a more formal representation for ABBI than text, and JSON has emerged as a possible / favored candidate. That lead them to looking at FHIR to see whether we had anything to offer in this space.
Answer:
Well, FHIR certainly has a lot to offer – something that is developing quickly, but is on the standards track, that offers both XML and JSON (interchangeably, which isn’t as easy as it sounds), works with REST and the web, and is easy to use. But there’s something missing: FHIR doesn’t have a relevant resource for the core of the ABBI data set. So we had a fruitful interchange with some of the ABBI team, and they sent us some definitions and sample (real) data (yay – sample data – that’s what we like, real data), and we knocked up a straw-man Claim resource that would be suitable for use with ABBI data, that includes our own experience with claims data, and that is consistent with the way things are done in FHIR.
Since this is (presently) out of band work done at the behest of some members of the ABBI team, it’s not going to be part of the FHIR spec published at http://hl7.org/fhir (for now, at least). Instead, it’s published here:
Claim Resource
Covers both initial claims (invoices) and adjudicated claims (EOBs – Explanations of Benefits). UML:
Note: there’s a problem with the representation of subline – it should be a relationship back to Line (Something for me to investigate in the tooling).
The XML definition for this is:
<Claim xmlns="http://hl7.org/fhir"> <identifier><!-- 0..1 Identifier Id for this claim instance --></identifier> <adjudicating><!-- 0..1 Resource(Claim) For adjudication, what invoice is it --></adjudicating> <type><!-- 0..1 CodeableConcept Type of claim --></type> <period><!-- 0..1 Period Timeframe covered by claim --></period> <patient><!-- 1..1 Resource(Patient) Covered party --></patient> <billingProvider><!-- 1..1 Resource(Person|Organization) Who is billing --></billingProvider> <coverage><!-- 1..1 Resource(Coverage) What coverage is claim against --></coverage> <precedingClaims><!-- 0..* Resource(Claim) Other coverages billed --></precedingClaims> <netAmount><!-- 1..1 Money Amount to be paid --></netAmount> <allowedAmount><!-- 0..1 Money Revised amount to be paid --></allowedAmount> <coveredAmount><!-- 0..1 Money Amount paid by coverage --></coveredAmount> <nonCoveredAmount><!-- 0..1 Money Left to pay by patient and/or subsequent coverage --></nonCoveredAmount> <line> <!-- 0..* Breakdown of claim --> <code><!-- 1..1 CodeableConcept Billing code --></code> <modifier><!-- 0..* CodeableConcept Qualifiers for billing code --></modifier> <unitAmount><!-- 0..1 Money Amount paid/unit --></unitAmount> <unitQuantity><!-- 0..1 Quantity Number of units --></unitQuantity> <netAmount><!-- 1..1 Money unitAmount * quantity + sublines --></netAmount> <allowedAmount><!-- 0..1 Money Cap on amount allowed to be billed --></allowedAmount> <coveredAmount><!-- 0..1 Money Allowed net amount with adjustments --></coveredAmount> <service> <!-- 0..* Healthcare service item is for --> <type><!-- 0..1 CodeableConcept Service code --></type> <bodySite><!-- 0..* CodeableConcept Where on body was service done? --></bodySite> <period><!-- 0..1 Period Start and end date --></period> <performer><!-- 0..1 Resource(Agent|Organization) Who delivered service --></performer> <location><!-- 0..1 Resource(Location) Where performed --></location> <indication><!-- 0..* CodeableConcept Diagnosis or clinical reason --></indication> <details><!-- 0..1 Resource(ANY) Details of service --></details> </service> <adjustment> <!-- 0..* What's not covered & why --> <reason><!-- 0..1 CodeableConcept Reason for adjustment --></reason> <amount><!-- 1..1 Money Amount of adjustment (usually negative) --></amount> </adjustment> <subLine><!-- 0..* Content as for Claim.line Sub-elements of line item --></subLine> </line> <extension><!-- 0..* Extension See Extensions --></extension> <text><!-- 1..1 Narrative Text summary of resource (for human interpretation) --></text> </Claim>
Note that this is just a strawman for illustration purposes, to see what this would look like in json. So let’s see a couple of examples. First of all, let’s get the patient details out of the way. (and also, the formatting of this sucks compared to the standard FHIR representation, but the WordPress editor has defeated me in that regard this time around).
What the ABBI team provided:
Name: JACYLN BOURNE Date of Birth: 4/15/1941 Address Line 1: 415 EAST 71ST ST Address Line 2: City: NEW YORK State: NY Zip: 10021 Phone Number: Email: sample@bluebuttontrust.org Part A Effective Date: 11/1/2008 Part B Effective Date: 2/1/2009
Other than the Effective dates, which are really coverage information, this goes in the Person resource, and is represented in JSON like this:
{
"Person" : {
"name" : [{
"family" : "BOURNE",
"given" : "JACYLN"
}],
"telecom" : [{
"system" : "email",
"value" : "sample@bluebuttontrust.org"
}],
"birthDate" : "1941-04-15",
"address" : [{
"line" : "415 EAST 71ST ST",
"city" : "NEW YORK",
"state" : "NY",
"zip" : "10021"
}],
"text" : {
"status" : "generated",
"div" : "..."
}
}
}
Note that I was going to fill out the narrative in the div properly, but trying to represent html elements in the preformatted text throws the WordPress editor out, so you’ll just have to imagine something proper there.
Moving on, to the core of the data, here’s sample data provided by the ABBI team:
Claim Number: 9427984358334 Provider: MANHATTAN ENDOSCOPY CENTER L Provider Billing Address: CL #4685 PO BOX 95000 PHILADELPHIA PA 191954685 Service Start Date: 9/21/2012 Service End Date: Amount Charged: $386.60 Medicare Approved: $386.59 Provider Paid: $386.59 You May be Billed: $0.00 Claim Type: PartB Diagnosis Code 1: V1272 Diagnosis Code 2: 56210 Line number: 1 Date of Service From: 9/21/2012 Date of Service To: 9/21/2012 Procedure Code/Description: G0105 - Colorectal Cancer Screening; Colonoscopy On Individual At High Risk Modifier 1/Description: Modifier 2/Description: Modifier 3/Description: Modifier 4/Description: Quantity Billed/Units: 1 Submitted Amount/Charges: $386.59 Allowed Amount: $386.59 Non-Covered: $0.00 Place of Service/Description: 24 - Ambulatory Surgical Center Type of Service/Description: F - Ambulatory Surgical Center Rendering Provider No: A300070363 Rendering Provider NPI: 1124324181 Line number: 2 Date of Service From: 10/22/2012 Date of Service To: 10/22/2012 Procedure Code/Description: G8907 Modifier 1/Description: Modifier 2/Description: Modifier 3/Description: Modifier 4/Description: Quantity Billed/Units: 1 Submitted Amount/Charges: $0.01 Allowed Amount: $0.00 Non-Covered: $0.01 Place of Service/Description: 24 - Ambulatory Surgical Center Type of Service/Description: F - Ambulatory Surgical Center Rendering Provider No: A300070363 Rendering Provider NPI: 1124324181
Represented in JSON following the definitions in the Claim resource above, this looks like this:
{
"Claim" : {
"identifier": {
"id" : { "value" : "9427984358334" }
},
"type" : {
"coding" : {
"code" : "PartB"
}
},
"period" : {
"start" : { "value" : "2012-09-21" }
},
"patient" : {
"type" : "Patient",
"id" : "example-abbi"
},
"billingProvider" : {
"Organization" : {
"identifier" : [ {
"label" : "Provider No",
"identifier" : {
"id" : "A300070363"
}
}, {
"use" : "official",
"label" : "Provider NPI",
"identifier" : {
"system" : "http://us.gov/NPI",
"id" : "1124324181"
}
} ]
"name" : { value : "MANHATTAN ENDOSCOPY CENTER L" },
"address" : {
"line" : "CL #4685 PO BOX 95000",
"city" : "PHILADELPHIA",
"state" : "PA",
"dpid" : "191954685"
}
}
},
"netAmount" : {
"value" : "386.60".
"units" : "$"
}
"allowedAmount" : {
"value" : "386.59",
"units" : "$"
}
"coveredAmount" : {
"value" : "386.59",
"units" : "$"
}
"line" : [ {
"code" : {
"coding" : {
"system" : "http://cms.gov/Medicare/Coding/type-of-service-codes",
"code" : "1",
"display" : "Medical Care"
}
}
"unitAmount" : {
"value" : "386.59",
"units" : "$"
}
"unitQuantity" : {
"value" : "1"
}
"netAmount" : {
"value" : "386.59",
"units" : "$"
}
"allowedAmount" : {
"value" : "386.59",
"units" : "$"
}
"service" : [ {
"type" : {
"coding" : {
"code" : "G0105",
"display" : "Colorectal Cancer Screening; Colonoscopy On Individual At High Risk"
}
}
"period" : {
"start" : "2012-09-21",
"end" : "2012-09-21"
}
"location" : {
"Location" : {
"code" : {
"coding" : {
"code" : "24",
"display" : "Ambulatory Surgical Center"
}
}
}
}
} ]
},
{
"code" : {
"coding" : {
"system" : "http://cms.gov/Medicare/Coding/type-of-service-codes",
"code" : "2",
"display" : "Administrivia"
}
}
"unitAmount" : {
"value" : "0.01",
"units" : "$"
}
"unitQuantity" : {
"value" : "1"
}
"netAmount" : {
"value" : "0.01",
"units" : "$"
}
"allowedAmount" : {
"value" : "0.00",
"units" : "$"
}
"service" : {
"type" : {
"coding" : {
"code" : "G8907"
}
}
"period" : {
"start" : "2012-10-22",
"end" : "2012-10-22"
}
"location" : {
"Location" : {
"code" : {
"coding" : {
"code" : "24",
"display" : "Ambulatory Surgical Center"
}
}
}
}
}
}],
"text" : {
"status" : "generated",
"div" : "..."
}
}
}
Though there’s plenty of discussion to have around the exact design of the resource, and what elements there should be, etc, this is enough to show roughly what the output would look like using JSON resources as defined by FHIR. Coming cold at this, most readers would probably comment about a couple of apparently spurious levels of nesting, which equate to places for redirection or abstraction – such as code…coding…code, or location…Location. There’s good reasons for these nesting, though we’re still looking at cleaning this up so it looks better in the final instance.
p.s. Lloyd McKenzie did much of the preparative work for this post, including the original claim resource design – thanks.


Thanks, Graham and Lloyd!!!!!!
For folks just joining in, for clarification, this is related to work being done in the Payer content subworkgroup of the Automate Blue Button Initiative (ABBI), within the S&I Framework. (I know, it sounds like some Sacha Baron Cohen movie title — “XML and JSON for make glorious benefit of consumer access to health data”).
For ABBI, there is much more to the Blue Button world, i.e. patient-mediated view, download and transmit from EMRs and HIEs where Automated Blue Button now describes the preferred interoperable content standard (CCD from Consolidated CDA) and transport standard (DIRECT for the PUSH model; TBD for the PULL model, gravitating toward OAuth & RESTful approach). The tenet of the Blue Button work is that a patient/consumer-focused approach to enable zillions of developers from both startups & well-entrenched IT shops alike to build useful (meaningful?) applications for consumers — not just providers and payers.
The ABBI work is going on over here:
http://wiki.siframework.org/Automate+Blue+Button+Initiative
And drafts of implementation guidance are here:
http://blue-button.github.com/docs/
Happy New Year!