Stream: CARIN IG for Blue Button®
Topic: IG Feedback
Josh Lamb (Dec 13 2019 at 15:22):
@Amol Vyas At the connectathon we were given an opportunity to provide feedback on the IG. I wanted to open up a thread to capture this feedback. I am capturing this list from memory so anyone can feel free to include anything I missed or any new concerns.
1.) It would be helpful to provide expanded text descriptions on the properties for CARIN resources. The FHIR spec allows for profiles to expand text descriptions without applying additional constraints. Most of the descriptions are inherited from either the US Core or the base resource descriptions and I think we are missing an opportunity to provide clarity and example values. This will be especially helpful for healthplans that may lack experience working with FHIR or HL7 specifications.
2.) It would be good to specify use cases for the various resources. This will help to highlight the business value that the resources can create. For example, we could specify that the Coverage resource can be used as a virtual member id card. Or that the Organization resource associated with Payor can contain customer service contact information regarding the insurance policy. It was suggested that healthplans work with their customer service departments to determine pain points so that we can capture additional high value use cases for these resources.
3.) It would be helpful to publish the CARIN profiles to Simplifier.net. As of now the profiles are unclaimed on Simplifier. This will make the process of ingesting the profiles and performing validation easier in some cases.
Josh Mandel (Dec 13 2019 at 17:26):
To keep pushing on examples: I don't see any resource examples listed at http://build.fhir.org/ig/HL7/carin-bb/profiles.html . What data were used during the connectathon for testing?
Josh Mandel (Dec 13 2019 at 17:30):
For the "meat" of profiles on EOB, there's a long list of supportingInfo slices (see here for instance). These render like...
A couple of issues here (and with all the other slices):
- patientDischargeStatusCode has no documentation stating what this field means.
- patientDischargeStatusCode has no constraints indicating which sort of
value[x]it should have. - Assuming patientDischargeStatusCode is meant to use some kind of Code Coding or CodeableConcept as its value... I can't see how this works.
ExplanationOfBenefit.supportingInfo.value[x]doesn't support[x]of Code or Coding or CodeableConcept. I'm probably missing something basic here, but I'm having trouble determining what.
Josh Lamb (Dec 13 2019 at 17:56):
@Josh Mandel I agree that there should be descriptions of the slice definitions. If i am understanding your question, the name is confusing since patientDischargeStatusCode is not a code, the type is ExplanationOfBenefit.SupportingInfo. PatientDischargeStatusCode.value[x] supports boolean, string, quantity, attachment, and Reference(Resource).
Josh Mandel (Dec 13 2019 at 17:58):
But what does a "patientDischargeStatusCode" of true mean? or "foo"? or 15? Or {"url": "http://"...}? Or {"reference": "http://..."}
Josh Mandel (Dec 13 2019 at 17:58):
In other words, without documenting the meaning of the slice and providing constraints on the allowed values, defining a slice accomplishes nothing.
Josh Mandel (Dec 13 2019 at 17:59):
(Especially without examples showing the authors' intent and allowing a reader to guess.)
Josh Lamb (Dec 13 2019 at 18:02):
I understand your point. Everyone will interpret this differently without an explicit definition or constraints. I have been frustrated trying to populate this resource due to this very issue.
Josh Mandel (Dec 13 2019 at 18:10):
... and supportingInfo slices seem to be the majority of what's defined in the profiles.
Elkhan Yusubov (Dec 16 2019 at 20:07):
Hi @josh lamb - is there any registration for IG meeting to clarify the contained resources?
Josh Lamb (Dec 16 2019 at 20:21):
Hi josh lamb - is there any registration for IG meeting to clarify the contained resources?
I think that what we are saying is that we will probably not have any use case that requires a contained resource but we may want to support included resouces based upon how the server is being queried. E.g. calling GET on patient/123 would not include the organization that is referenced but performing a search with the _include=organization param would include organization. I liked Paul's suggestion to support a PatientEverything with a _since param. This would include all related resources by default.
Mark Scrimshire (Dec 16 2019 at 20:22):
The Da Vinci PDEx IG recommended the use of a Patient/123456/$everything operation.
Josh Lamb (Dec 16 2019 at 20:31):
Can anyone confirm that the data elements that must be supported as per the CPCDS are represeted in the profiles with a minimum cardinality of "1.." with a "Must Support" value of true? There was some concerns raised during the call that health plans would be omitting data elements that are required but this should not be possible if we are validating against the published profiles.
Michele Mottini (Dec 16 2019 at 20:34):
Resources returned by _include or $everything won't be contained - they'll just be side by side withing the returned bundle
Josh Mandel (Dec 16 2019 at 21:18):
Can anyone confirm that the data elements that must be supported as per the CPCDS are represeted in the profiles with a minimum cardinality of "1.." with a "Must Support" value of true?
In FHIR, these two modeling approaches (min cardinality "1..", vs Must Support=true) are used for two different purposes. "Must Support" might be used even for cases of optional elements (i.e. for things that aren't always present, but that a server must implement support for).
Paul Church (Dec 16 2019 at 22:07):
@Michele Mottini for context, at the connectathon some example data used contained resources and some clients found that problematic. In my opinion the use case was not suitable for contained resources; there was no particular reason they couldn't have been normal resources. We just need to make sure everyone is on the same page - there was some confusion over terminology.
Josh Lamb (Dec 16 2019 at 22:15):
@Josh Mandel Understood. Without both "1.." and MustSupport = true a property may be required but support would not be required.
The heart of my question was that I want some confirmation that validating against the profiles should reflect the CPCDS requirements.
Grahame Grieve (Dec 16 2019 at 22:29):
I'm not sure I follow this. By definition (for FHIR), required means cardinality 1..x. I do not know the CPCDS requirements, but typically such requirements include things that can't be validated in an instance (e.g. an element may be required to be present if some condition that is outside the resource being validated is true)
Josh Lamb (Dec 16 2019 at 22:50):
@Grahame Grieve thanks for the input, I was referencing a comment by @Lloyd McKenzie in the CARIN Benefit Check IG stream:
"b) 1..1 and mustSupport are orthogonal. If something is 1..1 and not mustSupport, then nothing stops the sender from populating the element with a fixed value (or even a fixed extension that says something like 'not supported'). And on the receiving side, a mandatory element not marked as mustSupport is free to be ignored and thrown away. mustSupport is what sets conformance expectations that the system must be able to store/display/"allow user entry of"/"consider in decision support"/"do whatever with" the element. So typically if an element is 1..1 it will also be flagged as mustSupport."
Grahame Grieve (Dec 16 2019 at 22:51):
yes typically, but not always. (there's always edge cases)
Michele Mottini (Dec 16 2019 at 23:34):
Got it @Paul Church , thanks. And yes, contained resources won't sit well with most clients
Josh Lamb (Dec 17 2019 at 21:41):
Can someone also point to the licensing requirements for the codesystems used within ExplanationOfBenefit resource? I was going through the terminology within https://build.fhir.org/ig/HL7/carin-bb/terminology.html and its not clear what code systems require a subscription to get the full set of values. My assumption is that anything provided by hl7.org will not require a subscription. @Zanub Malik FYI
Grahame Grieve (Dec 17 2019 at 21:43):
any code systems we define do not require a commercial license -they have some kind of open source license.
but this is not necessarily true of any code systems that we 'provide' - in that many code systems have a license such that we can distribute the content to you as part of an IG, but you have to acquire a license to use it. We should say so explicitly on each on of these
note that this is general advice; I haven't looked at this particular IG
Josh Mandel (Dec 18 2019 at 21:39):
From today's fmg call, there are outstanding build errors that need to be fixed if the guide is going to continue on to ballot:
-
need to update the hl7 logo, and
-
need to fix the footer
These can be fixed independently or by updating to the latest standard template.
Grahame Grieve (Dec 18 2019 at 21:41):
note: switching to the standard template is probably not such a good idea to do at the last minute
Josh Lamb (Dec 27 2019 at 16:58):
@Amol Vyas Within the IG I am seeing an error on Adjudication: "Unknown reference to #ExplanationOfBenefit.item.adjudication
Header-level adjudication".
Last updated: Apr 12 2022 at 19:14 UTC
