FHIR Chat · mappings to Coverage resource · implementers

Stream: implementers

Topic: mappings to Coverage resource

Aleksandra Pavlyshina (Jul 15 2016 at 12:37):

Hi All,
I'm looking for a way to communicate primary coverage vs secondary coverage, I found the gforge issue from @Michelle (Moseman) Miller without an answer. Could someone please advise what is the proper way to do it?

Aleksandra Pavlyshina (Jul 15 2016 at 14:01):

I'm working on mapping an application form to the Coverage resource and can't understand,
how to convey information about an insured person (name and contact information).

E.g. a planholder is a patient's mother and beneficiary is the patient itself.

As I understand, it should be conveyed in the Coverage.planholder,
but by resource definition it should be of data type Identifier or Reference to Patient|Organization, and there is not RelatedPerson option .

Is issuera proper field for insurance company?
Please help.

Coverage (DomainResource)
status : code [1..1] « CoverageStatus! »
issuer[x] : Type [1..1] « Identifier|Reference(Organization|Patient|
RelatedPerson) »
planholder[x] : Type [1..1] « Identifier|Reference(Patient|
Organization) »
beneficiary[x] : Type [1..1] « Identifier|Reference(Patient) »
relationship : Coding [1..1] « Policyholder Relationship »

Igor Sirkovich (Jul 15 2016 at 15:37):

@Sasha Pavlyshina, I see that Brian Postlethwaite has answered Michelle's question a few days ago: "These would also have different primary/secondary when applied to an encounter or episode of care."

In regards to your second question, I think you got it right: "issuer" (reference to Organization) would be an insurance company, "beneficiary" (reference to a patient) would be a patient (e.g. child) and "planholder" (reference to another patient) would be a plan holder (e.g. patient's mother). The "relationship" code would be "child": "The relationship of beneficiary (patient) (subscriber) to the the planholder". I'm not sure why the committee had decided to model this way rather than allowing "planholder" reference "RelatedPerson", which would eliminate a need for "relationship" element, but this model seems to work too.

Aleksandra Pavlyshina (Jul 15 2016 at 20:58):

@Igor Sirkovich, thank you for your answer.
Can I ask you how do you understand Brian's asnwer?

Andy Stechishin (Jul 15 2016 at 21:04):

@Igor Sirkovich The RelatedPerson requires (1..1) a Patient so if you create a Coverage where planholder and the beneficiary are the same (relationship is SELF) you then need to create a RelatedPerson and Patient where the RelatedPerson has identical information. Note also that if you used the RelatedPerson, and you created two Coverage resource for a brother and sister, you would need to create TWO different RelatedPerson resources as opposed to having the planholder on both of the Coverage resources point to a single Patient resource

Igor Sirkovich (Jul 15 2016 at 21:30):

Thank you @Andy Stechishin. This makes sense.

Igor Sirkovich (Jul 15 2016 at 21:43):

@Aleksandra Pavlyshina, sorry, I see that this was a follow-up request rather than an aswer. This new request is for primary or secondary flag / indicator in context of an encounter or episode of care. The resolution for the original request was to re-open post DSTU-2, so you are right, it has been addressed yet. @Andy Stechishin, @Lorraine Constable, I'm wondering if this is going to be addressed for STU-3.

Andy Stechishin (Jul 15 2016 at 21:57):

@Igor Sirkovich @Aleksandra Pavlyshina primary and secondary sound simple until you try to apply them to the real world. For instance Igor, you would likely say for hospital coverage your primary is Ontario Health and the secondary is your Group Health Plan. But if you slip on ice in front onf your workplace while going on a work-related item, the primary just became Ontario WCB. So in and of itself, a Coverage has no concept of primary or secondary, it only has primary or secondary context when associated with something like a claim item and the circumstances surrounding that item.

Aleksandra Pavlyshina (Jul 15 2016 at 22:43):

Thank you @Andy Stechishin for the clarification.
Just to make clear the case when planholder and beneficiary are different persons (e.g. mother - insured and child - patient).
Do we need to create Patient resource for mother (so we could record Insured Name, Insured Phone #) and use it in the Coverage.planholderReference?

Andy Stechishin (Jul 15 2016 at 22:50):

@Aleksandra Pavlyshina likely you would create a Patient resource for the mother in any event. In most cases (but not all), you would have a Coverage resource where the relationship was self and planholder and patient are the same, so for the majority of situations this presents the optimal arrangement. If you were however only recording Coverage for underage patients or you were recording Coverage in a veterinary situation the Patient resources created for the plaholders would be additional

Aleksandra Pavlyshina (Jul 15 2016 at 23:01):

@Andy Stechishin @Igor Sirkovich, thanks a lot for your responses!

Keith Boone (Oct 06 2016 at 15:54):

I would never be a patient in my wife's Ob/Gyn practice, nor in my daughters' pediatric practice. Yet I am certainly the planHolder. The resource should allow a choice of RelatedPerson (for which I created a tracker).

Brian Postlethwaite (Oct 09 2016 at 23:54):

What's the tracker number for that one?

Aleksandra Pavlyshina (Oct 10 2016 at 16:06):

It's #7772 Summary: 2015May core #1093 - Use person instead of patient for Coverage.

Paul Knapp (Oct 13 2016 at 12:59):

No to all. Patient is FHIR's resource for capturing a person who isn't in teh role of a practitioner - you have to ignore the name - they aren't necessarily in the role of a patient (but they could be.

Typical example: Dad has family healthcare coverage through his work which applies to Mom and children Suzie and Johnny. If Suzie is receiving treatment then she and Dad will both have patient resources entered and on the Coverage resource the PlanHolder would point to Dad's Patient instance and the beneficiary would point to Suzie's Patient record.
You would not use a RelatedPerson record for Dad as that would require potentially 4 RelatedPerson records for Dad since RelatedPerson has a mandatory reference to the party they are related to you would need: Dad->Mom, Dad->Dad, Dad->Suzie, Dad->Johnny.
You would not use Person as it is not a demographic record for an individual, it is a list of individual type resources which all describe the same individual.

Note: Originally Patient was called Person, then it got renamed to Patient but its purpose wasn't changed, just the resource name was.

So yes, in my veterinarians system, if it was FHIR based, I would be in the Patient file along with my dogs, cat, rabbits, horses etc. - odd but true. (Otherwise there would be 15-20 RelatedPerson records for me, and the same for my wife.)

Lloyd McKenzie (Oct 14 2016 at 03:55):

@Paul Knapp Disagree. In the Veterinarian's system, from FHIR's perspective, there would be 15-20 RelatedPerson records for each of you. You could have a single Person record to link all of them. But you wouldn't be a Patient because you're not a recipient of services (unless you're there as a Patient from a billing perspective - when you might well be the focus of the activity).

Paul Knapp (Oct 14 2016 at 05:16):

I don't understand what you are saying:
That there wouldn't be 15-20 RelatedPerson records? or that there would and that you could have a single Person record link all of them - all of what?

The multiple RelatedPerson records?: Then the Person record is yet another record - and for what purpose?. (I can't see why an implementer would do this let alone why they would create 15-20 redundant owner records.)
The multiple Patient records?: How, they aren't the same individual?

As the owners we are subjects of billing activity and we are also the PlanHolders of Health Insurance where the Patient is the beneficiary.

Lloyd McKenzie (Oct 14 2016 at 15:58):

@Paul Knapp There'd be a Patient record for each animal. The only way to link those patient records to the animal's owner is RelatedPerson. So you'd need to have a RelatedPerson record for every animal. The purpose of the Person record would be to allow you to establish that all 15-20 RelatedPerson instances referred to the same human being. Presumably in the Veterinary environment, you'd choose to maintain the demographic and contact information for the owner on the Person record rather than on each RelatedPerson. (The RelatedPerson would be limited to the mandatory reference to Patient, the role (owner) and possibly period and the active flag.)

Paul Knapp (Oct 14 2016 at 15:59):

Well that's not a winning design.

Lloyd McKenzie (Oct 14 2016 at 16:03):

Well, the ownership relationship needs to be specific to each animal - the period, status, etc. are independent. The same would be true in the human world - there's an NK1 v2 segment representing "me" for each of my children and my spouse. It's just that in the veterinary world, there can be considerably more animals than kids - particularly if you're a farmer. The design still allows for centralized maintenance of the demographic information and the resource boundaries are clearly set at what's independently maintainable and has its own status.

Sandeep Giri (Oct 18 2016 at 18:46):

The resolution for http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_id=677&tracker_item_id=7772 says "Will re-open post-DSTU2 publication" -- so, until then, our options are to either create a Patient record for the "subscriber" reference (even if the subscriber is not really a patient receiving services), or create an extension to link Coverage to a Person (without creating Patient) ..?

Lloyd McKenzie (Oct 19 2016 at 01:50):

Person is intended only as a linkage resource - it allows you to say that multiple Patient, RelatedPerson and/or Practitioner instances all refer to the same individual and to centralize the maintenance of certain demographic information. Person should never be a direct participant in any resource. Subscriber would need to either be Patient or RelatedPerson.

Brian Postlethwaite (Oct 19 2016 at 02:54):

Agree with this Lloyd, I think that the RelatedPerson needs to be included in the options there with Patient (I actually thought it was, but was mistaken)

Paul Knapp (Oct 19 2016 at 07:25):

Agree that Person should not be used - if it is the indexing resource that it was originaly described to be. RelatedPerson could be added, but if a user needs any demographic information other than name, gender, birthdate, address, phone number then they are going to have to use the Patient resource anyway.
I think there is a serious confounding of entity and role in the Patient, RelatedPerson, Person resources which are now leading to design and usage which is just wrong - as in not what actual implementers would do.
This may be the last time we can clean this up - rename Person to PersonIndex or Personlist and drop as much of its demographics as appropriate; rename Patient to Person and add an optional element to provide a list of references to related Persons, drop RelatedPerson as it can now be handled by Person (add a personType code if neccesaary to convey the overall role of the record: friend, patient, family, etc) and then the patient/subject/etc elements in resources would reference Person in respect of their role within that resource.
This, I think, would seriously help to manage the confusion driven by the names of the resources as well.

Lloyd McKenzie (Oct 19 2016 at 16:08):

Patient is not "person". It's an individual who can receive service. I'm ok with renaming Person to PersonLink or something like that to minimize the chances of it being used. RelatedPerson is someone who can act on behalf of a Patient - that's a different role from Patient.

Sandeep Giri (Oct 19 2016 at 16:16):

Thanks for the feedback. In an ACO scenario where you have multiple care providers in a network, each with their own EHR systems, it is desirable to have multiple Patient records linked via a common "Person" type entity - to represent a single human being with Patient records at each EHR where they have received service. This way, person-specific information such as contact information, gender, dob, insurance coverage, PCP can be represented at person-level (from ACO's perspective). That has been our rationale to create/maintain a Person entity at "network-level" with links to each Patient entity in the EHR's in the network. Hence the desire to link Coverage to this Person.

Following your recommendation though, we'd need to create a RelatedPerson entity to show the relationship between a person (policy-holder) to a patient (e.g. dependent), and then link the Coverage to the RelatedPerson -- correct? However, this would require Coverage resource to allow to link to RelatedPerson, which it currently doesn't.

Greatly appreciate your clarifying these concepts.

Brian Postlethwaite (Oct 19 2016 at 20:32):

Jsut a little more on the Person resource, its not just a linkage resource for linking various personish resoruces as the same one. It is a registry service that is a list of names that may or may not be patients. Some systems may use it as a source for creating new patient entries. And will often be exposing a membership list from other systems. (Not all members are patients, and shouldn't "flood" the systems with entries.

Paul Knapp (Oct 23 2016 at 06:18):

@Lloyd McKenzie: Patient is an individual, I don't know what you mean by 'not a person' - certainly it isn't the same as the Person-Linking resource.. I think roles are best expressed through resource elements.

I'm concerned about the number of what now 'seem' to be first-order resources for individuals - practitioner is fine, but Patient, RelatedPerson and Person now all appear to be being put forth as proper individuals to which one could/should use/refer when you need to refer to an individual - and they don't have a common content model!

I can see the value of an individual resource, and to express their role and relations to other resources within that instance, and the value of having an indexing resource, but it shouldn't also appear to be a first order individual. By approaching this way you would compress out the non-benficial diversity of element ?..? Patient|RelatedPerson|Person to be just element ?..? Individual.

If the role of the individual was pateint then:
Resource.patient ?..? Individual
if the role was owner
Resource.owner ?..? Individual
If you have relationships
Resource.related ?..?
Resource.related.relationship 1..1 coding
Resource.related.person 1..1 Individual

I'm not advocating for calling the individual resource 'Individual', I think 'Person' may resonate better and result in fewer questions and less misunderstanding than we currently have, and simpler - cleaner designs.

Lloyd McKenzie (Oct 24 2016 at 01:42):

Person can't be referred to directly. Patient is used to refer to a service recipient. RelatedPerson is used to refer to an individual who is not a service recipient but is acting in their capacity of having a relationship to the service recipient rather than through their professional capacity. Practitioner is used to represent someone who is acting in their professional capacity. Whenever we are interested in a "person" (or animal) we're interested in them in one of those 3 capacities - service recipient, professional or related to service recipient

Brian Postlethwaite (Oct 24 2016 at 02:37):

This is correct Lloyd, and adding to that, clinical records and security will typically be applied to the patient record, a person doesn't have any context or information related to be secured. Could just be an organizations membership list.
(This could be a list of people who are potentially eligible for services, but have no patient records or history to see)
Other examples of Person records - Insurance company membership list, local council rate payers, members of an organization (e.g. Keiser Permanente), National/State/region-wide master index.

Paul Knapp (Oct 25 2016 at 12:01):

I think you are saying two different things, but perhaps not: i think Lloyd is saying you never reference the Person as an instance of an individual, you would only referece them as: Patient, RelatedPerson or Practitioner. And Brian is saying clinical record refer to the Patient record and that [something] could just be a membership list - I'm not getting what that something is: RelatedPerson or Person.

From the discussion the three types of individuals appear to: be individuals who receive care (Patient), individuals who provide care (Practitioners) and others (RelatedPerson). Except that RelatedPerson has a mandatory 1-1 mapping to a Patient - so it isn't just others and it forces redundancy in that you have to create a new instance for each relationship and cannot create an instance, for example for a member, if there isn't a person receiving (or capable of receiving) care.

Presumably not Person, but for RelatedPerson there must be a related Patient which isn't the case for a membership list. Also for a membership list, or list of insurance subscribers (Planholders) and beneficiaries, the RelatedPerson does not have all of the demographics of the Patient Resource.

Won't the fact that the same demographics are in two different places (an extension in one resource and an element in the other), or be missing, for the Patient and RelatedPerson be perceived as surprizing or inefficient?

Does this now create a situation where an individual will have a RelatedPerson record for their own coverage, with required demographics in extensions or missing, and a Patient record once they actually receive care?

Would the beneficiary be a RelatedPerson instance until they actually need care then we create a Patient record and update the Coverage to use that? or keep using the RelatedPerson and hope the insurer sees them as the same individual as the Patient? But if the Beneficiary is a RelatedPerson what Patient are they related to, must be themselves, therefore Beneficiary must always be a Patient - even if they aren't receiving treatment.

The Planholder could be either a Patient or RelatedPerson, yet if they are the beneficiary then they will have a Patient record. So the issue for Planholders is that using RelatedPerson is missing demographices for Planholders and the structures of Patient and RelatedPerson are different adn we need to create a reparate instacne for each relationship of an 'other; to a Patient.

Do we now need to create a Person instance to confirm the assertion that the RelatedPerson is the same as the Patient? Should we send that along too to show that we mean the two records we created for the same person are for the same person?

Which part of this is efficient or enabling?

Paul Knapp (Oct 25 2016 at 13:28):

Looking at this from another perspective: Dad burns his hand on the stove and goes to the hospital where they create a Patient-Dad record and record his health plan coverage with Patient-Dad as both the PlanHolder and the Beneficiary.

Two weeks later Mom goes into labour, they return to the same hospital wheer the Patient-Mom record is created and a Coverage record is created with Patient-Mom as the beneficiary - but who is the PlanHolder? A) Patient-Dad or B) a RelatedPerson-Dad-Mom record is created for Dad because: i) Dad can't receive obstetric services or ii) that's what we say to do.

Do we decide where and when an individual could be subject to services based on which department they are being seen by and therefore the resource type to use?

If Dad didn't have a pre-existing Patient record would we do something different?

Consider now from the insurer's perspective, are all of the insurer's beneficiaries in their Patient file because they could all be the subject of care somewhere? or are none of them in the Patient file as the insurer doesn't provide health care? And if none of them are Patients how can they be RelatedPersons when RelatedPerson requires a Patient?

Note: all planHolders are also beneficiaries by definition so they must go where the beneficiaries go.

Lloyd McKenzie (Oct 25 2016 at 16:37):

Practitioner is someone wh acts or is acted upon in their professional capacity (whether providing care or not). RelatedPerson is someone who acts or is acted upon in a non-professional capacity based on their personal relationship with the Patient (whether providing care or not). Patient is someone who acts or is acted upon based on their ability to receive care. Person never acts nor is acted upon. It exists purely to provide a shared identity and (sometimes) shared set of demographic information for the other resources. Most systems won't use Person at all. They'll maintain the demographic information independently for every role instance. The variations in the demographic information captured reflect variations in what information is typically relevant. Marital status is commonly known for patients, but not often relevant for Practitioner or RelatedPerson. If you need it, use an extension. The fact an element is core in one resource and an extension in another resource may be surprising to some, but is completely in-line with FHIR philosophy and design.

Beneficiary would always be Patient - because a Beneficiary is a potential recipient of care. Planholder would be RelatedPerson because they are never (intrinsically) a care recipient, but must have a (non-professional) relationship with the Beneficiary. The messy bit is that RelatedPerson is set up to be tied to a single Patient. And for Coverage, you can theoretically list multiple Beneficiaries, each with distinct relationships. That said, many healthcare systems don't track things that way - there's a separate Coverage instance per Patient, regardless of whether it happens to be a single plan.

The fact that the same person will typically exist as Patient and as multiple RelatedPerson records is standard. As is capturing the demographics separately. If my wife changes her phone number and tells our doctor, that'll get reflected on her chart. But it probably won't be reflected on my chart as her next-of-kin record. (If it does magically happen, then it's because the system is using the equivalent of Person to establish a linkage between her Patient resource and my RelatedPerson resource.

Paul Knapp (Oct 25 2016 at 19:00):

I guess that depends on the system design - I've never seen an EMR where you have to manage manually multiple records for the same individual, that would be an inefficient and unsafe design. Except for them being separately respresented a Practitioner, the Individual who receives service and one who hasn't/doesn't aren't separated.

Paul Knapp (Oct 25 2016 at 19:06):

You missed the key question, if an insurer has a FHIR server are all of the beneficiaries in Patient or none of the beneficiaries in Patient?

Grahame Grieve (Oct 25 2016 at 19:10):

I have seen it. You should not declare it as unsafe unless you first investigate the reasons for it, and the business practices around patient record management

Lloyd McKenzie (Oct 25 2016 at 19:16):

@Paul Knapp It's actually exceptionally common. In many places policy would explicitly prohibit any linkage of the fact that my wife as next of kin is also a Patient in the system - that would be considered a privacy breach.

My assertion is that the Beneficiary would always be Patient. They are always in the role of an actual or potential recipient of healthcare services

Paul Knapp (Oct 25 2016 at 19:20):

And so the policyHolder being always a beneficiary is always a Patient too right.

Lloyd McKenzie (Oct 25 2016 at 19:26):

The policy holder isn't a potential or actual recipient of healthcare services - they just hold the contract that covers the beneficiaries. So, in general, they would be RelatedPersons. They are involved with the patient's coverage by nature of their relationship to the patient (spouse, parent, employer, etc.)

Lloyd McKenzie (Oct 25 2016 at 19:27):

There's a small challenge in that the relationship is the reverse of what's usually expressed. Normally you convey what's the Beneficiary's relationship with PolicyHolder, rather than the reverse which is what RelatedPerson as Beneficiary would convey.

Paul Knapp (Oct 25 2016 at 19:32):

"elationship is the reverse of what's usually expressed" no you have misunderstood - individual who is holder of a health policy is normally also covered by the policy - if they are human.

Lloyd McKenzie (Oct 25 2016 at 20:46):

Sure. So in that case, if you want consistency you can have a RelatedPerson with relationship of "self". Or you could send Patient as both the beneficiary and policy holder if you want to allow for a choice.

Paul Knapp (Oct 26 2016 at 05:56):

Then how does your prior comment fit in "But you wouldn't be a Patient because you're not a recipient of services (unless you're there as a Patient from a billing perspective - when you might well be the focus of the activity)."? Was this an observation that the individual may already be a Patient, or that individuals who are billed would be Patients by virtue of their involvement in the billing activity?

Lloyd McKenzie (Oct 26 2016 at 17:17):

If the Patient is both beneficiary and plan-holder, then it's reasonable to use Patient for both - because it is the person who's the potential recipient of care. However, it would not ever make sense to use Patient as planholder if they're not someone who can receive care in the context in which the Coverage is being discussed.

Paul Knapp (Oct 26 2016 at 17:23):

So what do you do in a hospital which has numerous contexts? First one wins? Each time the user changes the beneficiary type? Does this mean you will create two Coverages one for Dad as a Patient in the ER and one for when Mom is delivering and Dad can't be a subject of obstetrical care?

Lloyd McKenzie (Oct 26 2016 at 17:27):

If you're storing as pure FHIR, then the data probably will exist more than once (possibly linked and kept consistent with Person). If you're using a legacy persistance layer, then you can store the data however you like and will expose it with Patient when appropriate and with RelatedPerson otherwise.

Lloyd McKenzie (Oct 26 2016 at 17:27):

(that's if your persistence layer has a single business object - and lots of legacy business layers will have different representations for each and no awareness they're the same individual.)

Paul Knapp (Oct 26 2016 at 17:31):

That fails to answer the question, duplication where you can't determine that they are the same person is unsafe and impractical. And leads to creating not just duplicate individual records but duplicate Coverage as well so now you have less interoperability and more work. Not what the implementers are looking for.

Brian Postlethwaite (Oct 26 2016 at 20:50):

The Patient.Link can reference RelatedPerson resources, so you can know if a Patient is a RelatedPerson also (without the Person too)

Lloyd McKenzie (Oct 27 2016 at 00:07):

Duplication is exceptionally common and there's no safety issue. I've got a name and contact info for the benefactor and name and contact info for the planholder and a relationship between them. Whether they're the same resource instance doesn't matter. And whether their phone number gets updated on one and not the other is also not an issue. (In fact, there are use-cases where the contact information could well be different for the two different roles.)

Stephen Royce (Oct 27 2016 at 00:11):

You've obviously never worked in a CRM context. "Whether their phone number gets updated on one and not the other" most certainly is an issue there.

Lloyd McKenzie (Oct 27 2016 at 00:49):

If you want to do that, Person exists to allow it to occur. With it, you have the capability to manage demographic information across multiple roles - and still choose what demographic information gets exposed where.

Stephen Royce (Oct 27 2016 at 02:32):

Paul Knapp (Oct 31 2016 at 05:56):

Creating duplication by design and then needing a further record to manage the duplication is surprising and not efficient.

We can add RelatedPerson to the PlanHolder, I just don't think this provides an efficient data exchange model and I know it creates challenges to having an efficient persistence model.

Lloyd McKenzie (Oct 31 2016 at 17:57):

@Paul Knapp FHIR isn't focused on persistance - efficient or otherwise. It's focused on making exchange as easy as possible between systems that may have very different internal models. As such it is, by definition, somewhat inefficient. If we send a message with 50 different resources, all 50 of them have to point to the Patient resource, even if it's the same. (And most will point to the same small set of Practitioner resources too. We expect narrative to be present to allow for maximum downstream interoperability (in systems and in time). The notion of maintaining distinct sets of demographic information for the same person with different roles or in the context of different patient records is extremely common in healthcare. Therefore, the base design supports that approach. For those systems that are more sophisticated and wish to maintain shared demographics, the Person resource provides that capability. But we're certainly not going to force a Person approach when the vast majority of systems don't (and often can't) do that.

Last updated: Apr 12 2022 at 19:14 UTC