In EDI (HIPAA 270 and 271) there are two types of patients - subscriber and dependent. In the latest DSTU (https://www.hl7.org/FHIR/2017Jan/eligibilityresponse.html) if I need to carry subscriber (not patient) and dependent (patient ) information in FHIR then I need ElgibilityRequest resource that references patient via EligibilityRequest.patient. But there is no reference to subscriber.
Instead, I have to get EligibilityResponse, extract reference to coverage which cannot be extracted via _include since it is not a part of search parameters (https://www.hl7.org/FHIR/2017Jan/eligibilityrequest.html#search) . Next I have to take Coverage.subsciber to get reference to RelatedPerson and pull out that resource.
So as you might see that is not very comfortable way to extract Subsciber information when he is not patient. I have to get Coverage and after get RelatedPerson resource to get them. Would that be more logical to include reference to Subscriber in EligibilityResponse and EligbilityRequest resources and make this field searchable?
The subscriber is a choice of a few resources on Coverage which is referenced from the EligibilityReqest resource. You are free in FHIR to create your own searches, you aren’t limited to those proposed in the specification if you have a business case for that search. I appreciate that you must traverse a few resources to get the desired information but that is how FHIR works.
Can you please explain why you would like or need the subscriber to be a first order element on EnrollmentRequest, and by that do you mean subscriber referencing a choice of entity resources or having subscriber as a subclass with all of the Patient or RelatedPerson elements as elements of the EnrollmentRequest.subscriber subclass?
Would you extend this to include all of the other elements of Coverage?
Is this to satisfy your needs to look into your server or for you to make available to others to search your server?
Sorry for all of the questions but it helps to understand your intentions and to determine whether this meets the guideline of ‘most people need or use this capability’.
Hi,
My proposal was to include subscriber reference to EligibilityRequest and Response since it is used in 50% use cases (when there is a dependent). Yes, subscriber can be accessible via jumping from EligibilityRequest --> Coverage --> RelatedPerson. But that seems wierd as far as Coverage is not mandatory in eligibility request while subscriber info (stored in related person in this case) is mandatory. If you look at EDI HIPAA files (270 and 271 transactions) you will see that subscriber is a loop within 270 transaction and it is mandatory. Thus converting EDI data to FHIR I would need always to create this chain of resources (EligibilityRequest --> Coverage (only one field subscriber I need) --> RelatedPerson) while dependent info is stored in more logical EligibilityRequest --> Patient, i.e. referenced directly from EligibilityRequest. The same works for ElligibilityResponse.
Can you please explain why you would like or need the subscriber to be a first order element on EnrollmentRequest, and by that do you mean subscriber referencing a choice of entity resources or having subscriber as a subclass with all of the Patient or RelatedPerson elements as elements of the EnrollmentRequest.subscriber subclass?
It is about Eligibility not about Enrollment. I do not need it as a first element, It should be any element in EligibilityRequest and Response , see my explanations above.
Would you extend this to include all of the other elements of Coverage?
No, see explanation where above.
Is this to satisfy your needs to look into your server or for you to make available to others to search your server?
As I think it is pretty common use case when you request eligibility and you need to carry information about Patient and Subscriber and do not need coverage details. Coverage is always used in Enrollment but absolutely not mandatory in Eligibility. That is why I am suggesting this edit for the next version of FHIR.
Ok, I understand your use case. Let me expand on FHIR a bit.
FHIR resources are intentionally designed to have maximum optionality so that they may be used in any situations. Therefore, to create a useful exchange within a community, for example US eCLaims, we would need to create profiles which allow us to constrain cardinality (make fields required) and set the valuesets (we use specified sets of codes). So when you look at the financial resources you get a false picture if you assume this is what we expect from an information requirements perspective.
If we have US realm EligibilityRequest (271/270 equivalent) then coverage would be 1…1 (Required), and within Coverage identifier, subscriber, beneficiary, relationship, payor would be required and payor could only be an organization (an insurer) - this would be just like more other standards for Eligibility Request. (There would also be more required fields overall (name, address, gender, birthdate)
The Patient is intentionally redundantly supplied in EniligilityRequest because of FHIR rules around there being no context conduction, but otherwise FHIR chops what may be a single large content model in another standard into many smaller reusable content models to support reuse. SO yes you often have to transverse models to get to information, for example EligibilityRequest.coverage->Coverage.subscriber->RelatedPerson.name is the subscriber’s name (note that could be a Patient resource not a RelatedPerson resource).
And you generally can’t just supply the demographics of the subscriber and the patient (beneficiary) to the insurer and expect to get results as the subscriber may have multiple coverages with that insurer, so the insurer should want their: member/certificate/subscriber ID and the group or plan or class as well. Typically you have to fully describe the coverage to get past the gate if you will (different insurers and different countries have different ways of approaching this).
We are also creating information models which meet the needs of multiple countries but which may be trimmed down to meet the specific needs within each country. Having the coverage resource contain whatever level of plan information is required meets all (we hope) needs, whereas putting just the patient and subscriber in the EligibilityRequest would not meet the needs of any other country which I can think of. Andy then there would be the issue of where of the multiple places to look for the information, so we try to manage down redundancy.
We are pleased to discuss alternate approaches to meet the use cases now and in the future. Please join us if you can on the Financial Management calls on Friday’s at 1PM Eastern (US).
Thanks for the detailed feedback. I see what you mean. By the way you mentioned good point that it can be Patient instead of RelatedPerson which is a duplicate of the Patient that is referenced directly from EligibilityRequest, which was also confusing for me.
I mean:
EligibilityRequest
patient --> Patient
coverage --> Coverage.subscriber --> Patient
Above is a case when subscriber is patient. In my architecture I do not use coverage for cases like above when subscriber is patient because there is information duplication.
Thus, I get two bundles with results instead of one. Of course, it is two GET restful calls. If I had 1000 EligibilityRequest calls I would need to do 2000 calls to get EligibilityRequest, Subscriber and Depdendent info.
I am not sure that I am doing it in the proper way. There might be an easier way to do that. As you see writing complex queries I am trying to
minimize the number of restful calls to FHIR server
obtain one file result which is easier to process when I need to reflect the response on web page or transform to some custom format.
Could you please also refer me to the information about that conference call you mentioned? Is that a Webex session or telephone conference?