Stream: CARIN IG for Blue Button®
Topic: CPCDS Format
Christopher Gracon (Sep 09 2020 at 19:11):
I am fairly new to the CARIN IG for Blue Button. In trying to understand the CPCDS, we are trying to understand is this a layout for a data file, or is it really just a set of data elements? We have found mappings from CPCDS to the FHIR resources, but can not find anything which shows the actual layout of CPCDS beyond just listing the data elements and saying that it is a flat file.
Can someone please help us to understand what the CPCDS is to look like? Thanks.
Josh Lamb (Sep 09 2020 at 20:01):
CPCDS is a logical model not a physical data model. It was used during the development of the CARIN IG to help define the FHIR resources.
The CARIN IG defines an adjudicated claims API. Within the claims data there are references to other resources (patient/member, coverage, practitioner, etc). The data needed to fulfill the needs of the CARIN IG is defined through must support flags and required fields.
John Timm (Oct 02 2020 at 18:37):
Why do I see, in multiple places, mention of a flat file format to help bridge implementation support? There is a CPCDS CSV format to FHIR converter from Diameter Health [1], Synthea has a CPCDS CSV export option [2], and 1upHealth has a CPCDS to FHIR "data adapter" [3]. I have seen presentations from the CARIN Alliance where "flat file format" is literally written into the list of deliverables [4]. "Flat File Format Specification Representing CPCDS Data Elements" sounds like a "physical model" to me. It would be nice to see a "canonical" flat file specification, coming from the CARIN Alliance, for folks that are working with CPCDS and want a bridge to CARIN BB FHIR support.
[1] https://github.com/DiameterHealth/cpcds-converter
[2] https://github.com/synthetichealth/synthea/wiki/CPCDS-Export
[3] https://1up.health/products/cms-rule/cpcds-to-fhir
[4] https://www.carinalliance.com/wp-content/uploads/2019/07/CARIN-Blue-Button-Framework_071519.pptx
John Timm (Oct 05 2020 at 13:49):
@josh lamb any thoughts on the above? :point_up:
Josh Lamb (Oct 05 2020 at 14:07):
@John Timm several others are also interested in using the CPCDS as a physical model. Particularly vendors who want to have a standardized way to deliver an interoperability solution for payers. Payers who are utilizing a vendor may need to producing a CPCDS file. Payers who are creating an in-house solution may find it unnecessary to first create a CPCDS file.
@Amol Vyas may be able to point you toward the other initiatives around CPCDS that you have not already identified.
John Timm (Oct 05 2020 at 15:38):
@josh lamb @Amol Vyas Mapping first to a row/column format with some traditional ETL tools may be a valuable "stepping stone" towards CARIN BB FHIR support for some payers. If we can agree on what CPCDS looks like in CSV format, we could have a "standard" tool to go from CPCDS <-> FHIR (conceivably available in open source).
Ryan Howells (Oct 05 2020 at 16:14):
hi @John Timm A flat file format was something we discussed early on but we didn't know how much demand there would be for creating one (so it became a lower priority) and frankly, haven't had the time to work on it to date. We would welcome yours and others thoughts on what could be created that we could review as an implementation team and overall HL7 community.
John Timm (Oct 05 2020 at 17:13):
@Ryan Howells I have surveyed the CSV format used in a few different projects. I will circle back with my colleagues and see if we can come up with a "recommended" CSV format for CPCDS.
Ryan Howells (Oct 05 2020 at 18:34):
That would be great. Thank you!
Josh Mandel (Oct 05 2020 at 18:59):
I continue to recommend against trying to standardize a CSV structure here; it'll perpetuate confusion about what the canonical data models look like, and there's no need for a consensus standards process on something flat/limited in this way.
John Timm (Oct 05 2020 at 19:03):
@Josh Mandel I'm not suggesting a "normative" standard. I'm simply suggesting something that is "informative" / "recommended" if you want to leverage CPCDS as CSV.
Josh Mandel (Oct 05 2020 at 19:05):
That helps on the "long-term energy expended" front -- but keep in mind that the entire Blue Button IG at this point is still at the trial use stage. The notion of "CPCDS <-> FHIR" causes confusion because folks reading the spec come away with this impression that CPCDS is something independent.
Dharmesh Patel (Oct 08 2020 at 21:48):
@John Timm We are also looking at defining a recommended CSV format for CPCDS Data elements. Happy to collaborate and come up with a common format that is more reusable.
Spencer Kathol (Nov 09 2020 at 22:09):
Hi All, I was wondering if anyone has discussed the best way to format specific structured fields in the data dictionary. For example:
MapID 130 (Patient Name): Format as HL7 datatype XPN?
MapID 176 (Service Facility Address): Format as HL7 datatype XAD?
Does this seem like a reasonable way to handle this? Has anyone chosen a different approach?
Michele Mottini (Nov 09 2020 at 22:25):
Not 100% sure I am understanding the question, but names should be structured as http://hl7.org/fhir/datatypes.html#HumanName and addresses as http://hl7.org/fhir/datatypes.html#Address
Scott Robertson (Nov 09 2020 at 22:30):
@Spencer Kathol XPN and XAD are v2 data types. better to use v3 / FHIR, as suggested by @Michele Mottini
Spencer Kathol (Nov 09 2020 at 22:36):
@Michele Mottini @Scott Robertson the target format is certainly FHIR - we are attempting to define a flat file format using the CPCDS data dictionary with the expectation it will end up as FHIR HumanName/Address. My thought was HL7v2 notation seems to be a better fit to embed this structured data within a CSV flat file. Does that make sense?
Isuru Samaranayake (Feb 01 2021 at 12:28):
Hi I'm new to the context and trying to understand CARIN IG for BB. I wanted to know that having a CPCDS to FHIR converting mechanism would ease up the mapping task when creating FHIR resources. (eg: a place where we need to create CARIN profiled FHIR resources from an X-12 message or other custom message, having intermediate CPCDS could be an advantage or not?)
Josh Lamb (Feb 01 2021 at 16:40):
CPCDS is often used as an intermediate conversation when using a vendor solution. Some may find it easier to convert to CPCDS than directly to FHIR. Once the data is in CPCDS it can be ingested by a vendor and they can provide some or all parts of the interop solution.
Josh Lamb (Feb 01 2021 at 16:41):
Long term there may be benefits of going through the mapping process to FHIR, and it may be beneficial to have that experience in-house, but this is an implementation decision you will need to make. I hope this vague advice is helpful!
Isuru Samaranayake (Feb 01 2021 at 19:04):
Thank you @Josh Lamb for the clarification. :smile:
Last updated: Apr 12 2022 at 19:14 UTC
