Patient income and household members seem to be included in a number of EMR's (e.g. Epic, OpenEMR), but I can't find the FHIR resource that includes these two parameters.
Is anything defined?
Those would be captured as Observations. They're point-in-time (and often reported) assertions. You might find the LOINC codes 77244-2 and 86639-2 helpful.
Related
Let me show tesla's company facts data with sec's RESTful api:
https://data.sec.gov/api/xbrl/companyfacts/CIK0001318605.json
You can see all labels in 'facts ---- us-gaap' such as :
AccountsAndNotesReceivableNet
AccountsPayableCurrent
AccountsReceivableNetCurrent
AccretionAmortizationOfDiscountsAndPremiumsInvestments
Do all listed companies share same us-gaap label names ?
Can every company create its own customerized us-gaap label names?
concept in xbrl is A taxonomy element that provides the meaning for a fact in the official definition.
https://www.xbrl.org/guidance/xbrl-glossary/
What is the difference between concept in xbrl and us-gaap's label ?
The short answer is yes.
First, a small detail:
AccountsAndNotesReceivableNet
AccountsPayableCurrent
AccountsReceivableNetCurrent
AccretionAmortizationOfDiscountsAndPremiumsInvestments
These are not labels, these are local names of concepts. Labels are something different, human readable, for example "Accounts and notes receivable, net" would be a label. Labels are attached with the label linkbase.
The more complete names (called QNames) of these concepts are:
us-gaap:AccountsAndNotesReceivableNet
us-gaap:AccountsPayableCurrent
us-gaap:AccountsReceivableNetCurrent
us-gaap:AccretionAmortizationOfDiscountsAndPremiumsInvestments
where the us-gaap prefix is bound with the US GAAP namespace, which changes every year and is, for 2021:
http://fasb.org/us-gaap-std/2021-01-31
This makes explicit that these concepts are not maintained by companies, but by the Financial Accounting Standards Board. Thus, all companies filing their reports into the EDGAR system share these concepts.
Two important points:
Companies are allowed to create their own concepts. These are called extension concepts. You will recognize them because they are in a company namespace, not in the US GAAP namespace. Their prefix will not be us-gaap, but some company-specific prefix. These concepts are unique to each company.
An example for Tesla is:
tsla:AccruedAndOtherCurrentLiabilities
Concepts in the US GAAP taxonomy are updated every year, i.e., some get added, some get deprecated, some are removed. However, the FASB tries to maintain consistency across years, i.e., a concept will not suddently change its semantics one year to the next.
During development, an internal name is given to a particular feature. That name is then used in function and variable names. Later, when the UI and Documentation are finalized, a different public-facing name is assigned to that feature. Should variable names be renamed too to correspond to the new public name?
On one side, the public-facing name may change frequently and so it is unpractical to rename internal references all the time. On the other hand, it can create confusion in meetings and among new team members if a single feature has different names (should there be a spreadsheet that maps the public and private names?).
Is there an industry standard for this?
The concept of an "ubiquitous language" discusses how external and internal names should be consistent.
To quote this great article:
Ubiquitous Language is the term that Eric Evans uses in “Domain-Driven
Design – Tackling Complexity in the Heart of Software” in order to
build a language shared by the team, developers, domain experts, and
other participants.
Using consistent names makes it easier for all parties to understand concepts in the product and code.
Is there a good place to store patient interests in FHIR? (e.g. enjoy bike riding, scuba diver, etc..) I am considering using an Observation to capture this, but I wanted to make sure there wasn't another option.
Observation is appropriate. It's a single point-in-time assertion.
I'm attempting to find patients that have visited specific ICUs at a hospital (either PICU, NICU, or CICU).
I've looked at the Encounter 2 resource and the Location 3 resource but am not seeing anything that would:
Clearly identify a visit to an ICU and specify what type of ICU it was (PICU, CICU, NICU, etc)
Have the ability to search for patients by seeing who has visited said ICUs, possibly during a certain timeframe.
Find the Admission and Discharge dates to the ICU.
The closest I've found is the ServiceType on the Encounter 2 resource which has the following options:
Intensive Care Medicine
Paediatric Intensive Care Medicine
Neonatology & Perinatology
However, these are too general and don't directly provide the type of ICU or admission/discharge dates to the ICU.
Any suggestions on how to accomplish these goals are welcome. Thanks!
I'm assuming this is a FHIR R4 question:
To capture the details of services available at a location you should use the HealthcareService Resource. You then would search for all encounters of a location where a specific kind of service is available.
You mentioned Encounter.ServiceType only having insufficient options for your problem. This ValueSet is only an example binding. So you can replace it with a VS for your specific use-case.
I'm refactoring one of my projects - a shopping cart. One of the tightly coupled areas of my code is the "Viewer" class - to generate information for the user to see, it often needs a combination of two or more of the following objects:
The store catalog.
The customer's order.
The customer's mailing information.
I can't really break up the display methods, for various reasons.
Martin Fowler's Refactoring identifies this as a "Long parameter list" smell. The relevant refactoring here is "Introduce parameter object." I am, however, hesitant to do that, as doing so would couple loosely related data. It would also lock me to a very narrow one-to-one relationship between those three objects - while that would work for my application as it is now, it makes no real-world sense. (As there is only one store catalog, there can be many "Customer mailing information" objects, and each of those may be related to many "Customer's order" objects).
Does anyone have any elegant solutions to this?
A parameter list of three parameters needs no refactoring. Start worrying when you reach, say, 8 or 10 parameters.
Try to name the thing that binds a catalog, an order, and an address. Start, maybe with CatalogOrderAddressTuple. Ugly, isn't it? Well, maybe as a utility class of your Viewer, it should just be an inner class, where you could get by with just Tuple - or Data. Still ugly.
It doesn't sound like these belong as actual fields to the Viewer - but explore what that would look like, how your code would change if each Viewer were simply constructed with the data on which it operates.
As ammoQ & Ryan Prior have said, this isn't much of a smell, but I'd say it's worth playing with some alternatives before giving up entirely.
As stated by ammoQ, looking for refactoring opportunities with so few parameters is stretching.
See also: KISS and YAGNI.
It seems to me that introducing a parameter object would have the opposite effect of locking you to a one-to-one relationship between those three objects.
If a single customer address is being passed around, and in the future someone decides to separate billing address and shipping address, then it would probably be simpler to add the new address to a parameter object, rather than add a new parameter up and down the call stack.
(This is just an example, of course. Ideally, the address information would exist separately in the order and customer objects, since all information on posted orders should be immutable, even if the customer's address changes. But that wasn't what you were asking about!)