Stream: implementers
Topic: Occupational data - resource vs. profile
Rob Hausam (Jun 04 2018 at 15:27):
The ODH (Occupational Data for Health) team and PHWG would like to get feedback from the implementer community regarding the extent that you currently capture or plan to capture occupational health data and how you do that (or plan to). If you're not entirely sure what this includes, the draft OccupationalData resource may help give an idea. It's been in the build as draft for the January and May cycles and some helpful comments have been received, but it would be good to get a broader idea of what the community would like to see going forward in this regard for FHIR. The main options are to progress the resource further or to instead represent the data as a profile (primarily on Observation). We want to answer the question of whether this this data is or is intended to be treated as somewhat independent and unique in regard to other types of observations and whether it should typically be recorded and kept together (leaning toward a resource) or whether much of it may be recorded and collected and used independently (leaning toward a profile).
Rob Hausam (Jun 05 2018 at 14:13):
@Michelle (Moseman) Miller @George Dixon @Emma Jones @Danielle Friend @Amit Popat ?
lori fourquet (Jun 05 2018 at 14:18):
@John Moehrke
lori fourquet (Jun 05 2018 at 14:24):
@Galen Mulrooney ?
lori fourquet (Jun 05 2018 at 14:28):
@Corey Spears
lori fourquet (Jun 05 2018 at 14:32):
@Keith Boone ?
lori fourquet (Jun 05 2018 at 14:32):
@Ron Shapiro ?
Galen Mulrooney (Jun 05 2018 at 14:59):
I would lean towards a resource rather than a profile, as there are use cases where one would want to query occupational data across patients (i.e., select everyone who has been working in the shipbuilding industry). While recognizing that profiles on observations are useful - especially where certain kinds of information are not captured uniformly for every patient (i.e., I've modeled (chromosomal) sex as an observation because it's a clinical test that is only done on some persons , while administrative gender is an attribute of every person), occupational history is relatively uniform (even across jurisdictions) and lends itself to a resource (and those who don't need it don't have to instantiate it). My $.02 anyway.
Lloyd McKenzie (Jun 05 2018 at 15:12):
The question isn't "what we might want", but "how do systems currently store this information".
John Moehrke (Jun 05 2018 at 15:36):
I have way too limited experience. But if I put my Privacy hat on, and Privacy does apply to employment data just as much as it does health data... It seems this might be more controllable as a Resource than a profile on Observation. We must have good controls on Observation, so this is not a really strong argument. However the data captured here is so very different than typical Health observations that it just feels wrong. So, give my vote very low weight, I vote for Resource. -- I look forward to EHR vendors perspective, and VHA perspective (where it is more convoluted).
Michelle (Moseman) Miller (Jun 07 2018 at 20:23):
Most of my feedback on this topic has been documented in GF#14465 already
To summarize:
-
Observation includes Social History, so we expose a lot of occupational data using Observations, such as School/Employment Status (Employed | Retired | Unemployed | Part time | Student), Work hazards (Vibration | Hazardous materials | Heavy lifting/twisting | Loud noises | Medical/Clinical work | Repetitive motion | Shift/Night work), Hazardous equipment operation (Yes | No), Activity level work (Desk/Office | Heavy physical work | Moderate physical work | Occasional physical work), Military service (Yes | No), Branch of military ( Army | Navy | Airforce | U.S. Coast Guard | Marine Corps), Current military status(Active duty | Reserves | Veteran), Military discharge (Honorable | Dishonorable | Medical) etc.
-
Employment-related demographics are also captured. Examples of the employment demographics (not represented as Social History Observations) include: employer organization, occupation code, position, employee status (full time | part time | retired | military etc.), employment type (long term leave | short term leave), hire date, term date, retire date, title, a contact (of who could verify employment) as well as military base location, etc.
George Dixon (Jun 12 2018 at 12:53):
Good summary. What is described under social is typically captured as charted observations. This can vary by client and specialty configuration.
What is captured under employment is standard and rarely altered configuration.
Probably not all that helpful but it depends.
Pls forgive any fat finger typos, Zulip and phone ...
Most of my feedback on this topic has been documented in GF#14465 already
To summarize:
* Observation includes Social History, so we expose a lot of occupational data using Observations, such as School/Employment Status (Employed | .....
* Employment-related demographics are also captured. Examples of the employment demographics (not represented as Social History Observations) include: employer organization, occupation code, position, employee status ...
Keith Boone (Jul 10 2018 at 15:44):
I lean completely towards profile of Observation. Observations apply to assessment responses, diagnostic tests and other sorts of collected data. We put these in the same context as we would any other sort of Social History observation, which fits into the same bucket in our database as diagnostic results. Querying occupation data can be done on observation using category fields, as well as value sets (which our product does support). Much of Social history collected for a patient follows the same pattern as occupational data.
Danielle Friend (Jul 13 2018 at 21:33):
If this is not a new resource, where would the relationship between patient, employer, and information regarding that specific employment be captured?
Lloyd McKenzie (Jul 13 2018 at 21:59):
I think the notion of "Employment" as a resource makes sense - one instance = one job. That would mirror how this information would typically be captured in v2. OccupationalData seems to be more of a reporting structure gathering a full employment history including a bunch of observation-like elements. At least one of the challenges with the resource as structured is that it doesn't allow you to easily put different access controls on different parts of a patient's employment history. Separating out each job gives you a clear status for the resource.
Mike Ryzhikov (Mar 12 2019 at 14:12):
Hello!
What resource should we use to capture data about the employment and education of the patient?
We're going to capture the following dataset:
Employment info
- company name
- job title
- date of enrollment
Education info
- level of education (incompleted, degree etc)
- educational organization
- dates of education (start & end)
Is it correct to capture the data about employment and education as observations (list + observations with category: “social history”)?
Lloyd McKenzie (Mar 12 2019 at 14:37):
Right now, our leaning is indeed to use Observations.
Lloyd McKenzie (Mar 12 2019 at 14:37):
@Brian Postlethwaite
Rob Hausam (Mar 12 2019 at 16:13):
You can also look at the ODH IG. It doesn't look like it currently includes everything that you want, but there's definitely overlap.
Brian Postlethwaite (Mar 13 2019 at 20:01):
That's the one Rob.
Last updated: Apr 12 2022 at 19:14 UTC