I have a service/database which contains employment information, provided by an employer, about their employees. I query this service with a search, like “list employees who have last name Smith, for any employer.” The response includes all matches for this search:
Who their employer is
What HR benefits (some are medical, some aren’t) this employer has
Which of my own company’s products this employer has purchased
Known information about the employee (such as the first name, their individually chosen insurance plan, other people they have listed as dependents)
I would like to map this information to appropriate FHIR entities. Are there any obvious resources that fit this pattern? I want to return all of the above information in a single response.
I looked at Claim/ClaimResponse/ExplanationOfBenefit but I’m not sure if EOB is appropriate because there aren’t claims involved.
HealthCareService looks like a good fit for the medical benefits, and possibly just for all HR benefits.
Human resources isn’t really in the scope except as it differs for the healthcare space - e.g. keeping track of practitioner’s training and licenses. Some of this - what coverage different patients have, and the fact that it’s employee-based coverage you can find using Coverage. But what HR benefits an employer has you’d need to use Basic to represent.
Thanks @lloyd. Using Coverage to link a Patient to Employer might work for us.
What about returning other known information about this person, like the employer told us their date of birth, and we’d like to get that information back? I’m also unclear how the searching of Coverage would work here, since the information we’re searching on isn’t patients per say, but a list of fields (like first name / last name).
What I struggle with for my use case is these aren’t stored as Patients (although the data represents a Patient), The stored data doesn’t have a Logical Patient IDs. The database is more a mapping of demographic fields to an employer. there’s no guarantee a Patient record has been created anywhere in the system, in fact we use the demographics returned by this service to know if we should create a Patient downstream.
Does it make sense to return demographic information (including employer) in a Patient resource, maybe with an ephemeral ID, even if there’s no true Entity of this Patient stored internally?
In FHIR, a Patient is an individual who receives or might potentially receive healthcare services. If you’re capturing demographics about such a person, you’ll need to expose that as a Patient resource. How you choose to store it inside your own system is totally up to you. From a query perspective, if you want to differentiate between people you consider “my patients” vs. “people who might eventually become patients”, you could populate the Patient.organization differently - e.g. set it for your patients and omit it if you don’t yet consider them “your” patients.