FHIR Resource Types

(Back to Main Page)

The initial set of resources is just a starter set. The following is a more extensive list. Those already listed are in bold. Feel free to edit. All proposed resources should be expressed as a plural. If the resource content won't be obvious, provide a description. And don't be overly fussed about the categories. They're quite arbitrary. At some point we'll need to prioritize these too, but lets build the list first. (In fact, some of these will likely never be built for years, if ever. It's just useful to think about where the stuff we have built or are working on would go.)

Principles

What makes a resource?

• needs a clear boundary, one that matches a logical transaction scope
• can refer to other resources.
• resources should differ from each other clearly in meaning, not just in usage (i.e. many ways to use a lab report...)
• resources don't really need to have a natural identifier, but they need to have a natural identity (i.e. a user level logical transaction scope)
• LM: This is already discussed in detail in FHIR Governance#When are new resources defined

(also see discussion of mood codes at bottom)

Resource References

General principle

• In most cases it's obvious which resource links to which
• When it's not obvious, it's probably a new linking resource. Any examples, discussion here please

Infrastructure

• Alerts (Presume this covers DetectedIssues?)
• AlertManagements (Presume this covers DetectedIssues?) (GG: Alerts? or management of something?)
  • In v3 right now, we have DetectedIssues (e.g. drug-drug interaction, no permission, etc.). We also have DetectedIssueManagements (which can be used to override detected issues, or at least identify how the issue will be dealt with). Is "Alert" the same thing as DetectedIssue, or is it something else?
• ChangeRecords (covers ControlAct) (GG: What do we need this for?; LM:how else do we capture metadata about changes (suspended by x because)?)
• Document (Covers 'header' structure) (GG: what has this got in it?; LM:Reason, links to other documents, author and similar information, document id, etc. plus structure/organization for the contained resources)
• ServiceMaster Files (GG: why? Why do platform stuff?; LM:This is masterfile stuff)
• (In theory, we could expose vocabulary artifacts this way too, if we treat CTS2 stuff as resources) (GG: I'd rather not create a turf war; LM: was assuming we'd just expose CTS stuff in the same way, only if Vocab is ok)

Stakeholder Resources

• Agents - (What are these? == AssignedPerson) ((GG: a person acting on behalf of an organisation - model is proposed)
• Departments (LM:Do we really need this as separate from Organizations?) (GG:Sub-orgs. Is a clinical service a org?; LM:I think we can deal with hierarchy as part of Org. There'll be lots of kinds of sub-orgs)
• Employees
  • LM: Not clear we have a use-case for this. Does anyone use HL7 for HR?
  • GG: Don't know why I had this and agent;
  • LM: You didn't. I added as a candidate. We can punt.
  • EK: Or maybe Employee is a subclass of Agent. Did we decide not to use subclassing between resources? (only in the implicit model that's behind it?))
  • LM: It could be, but in general we don't care about employee (payroll) relationships, but rather "chain of responsibility", which isn't always the same.
  • GG: No subclassing in resources (none in data types either). Subclassing belongs in definitions.
• Patients (EK: in my SMIRFS, this resource included validity verifications and administrative observations)
• People (GG: principle difference between patient and person is what things can point to it)
• Organizations
• Providers (GG: Why? What do we say about them? Is this organisations that play additional roles? Should it be agent? LM: We capture tonnes of stuff about providers in provider registry that we wouldn't for just general Agent - permissions, qualifications, licensing, affiliated SDLs, office hours.)
• Teams (EK: this is a group of people. Better name than "Group", which could group anything )
• PersonalRelationships - Use to register the fact that someone is a contact for someone else, familyrelations. LM and I discussed whether this was really a resource, could be nested data contained in a Person resource. Another doubt comes from the fact that this doesn't have a natural identifier, so it might not be a Resource after all.

• GG: Don't get this - we need names on the relationships.
• EK: As discussed on Skype, this only shows dependencies, so which resource references/uses/has knowledge of which other resources for now. No full specification of relationships yet.
• GG: ummm, so? How is it useful? I'd rather have something explaining the dependencies, or it's pretty meaningless to me
• LM: The Skype discussion degenerated into a "how do we represent this in UML?" discussion. However, I'll reiterate my assertion that (at this summary level) a concept map with named relationships would be most appropriate.

Other Participant Resources

• AccessPorts (tubes in and out of patients)
• Animals (GG: Aren't these patients? LM: Not always. Can also be work animals, subjects of clinical trials, other things)
• SoftwareApplications (Not sure this needs to be distinct from Devices) (GG: devices)
• DeliveryLocations - (Was Clinics. Need to encompass pharmacies, hospitals, etc.) (GG: Clinics was actually a group appointment rather than a location; LM: k. Can you put it where it needs to be)
• InventoryItems (Stuff that can be shipped) (Devices and materials can be shipped? LM: Y. bedsheets, etc.)
• Materials (Need to hold cosmetics and other stuff that's not necessarily specimens or devices)
• Places (GG: how different to deliveryLocations? We have places that aren't playing role of SDLs. E.g. Region covered by an investigation, EK: In my SMIRFS, places could be nested, just like in the v3 models: bed/room/wing).
• Products - This is the overarching term for devices and medications. But I suspect that the stuff that is in Material goes in here as well. It is effectively the CPM model but that sucker is too big, so there will be supporting resources (like Monographs as a start)
  • Devices
  • Medications
    • Monographs (moved from Pharmacy section)
• SchedulableResources (Items that can be scheduled not elsewhere covered)
• Specimens

Administrative Resources

• Appointments
• AppointmentRequests
• AccessRestrictions (covers masking, keywords, etc.) (GG: is this proper for a healthcare standard to do? LM:We do. Essential in Canada. Pretty sure it's used elsewhere)
• CareCollections - Groupings of acts related to a particular type of care or diagnosis
• InterestsOfCare (the notion that some clinical care provider has an ongoing interest in the care provided, such as a registered GP) LM: Don't understand)
• Contracts - (not sure if we have a use-case for this) (GG: what kind of contracts? LM: FM uses financial contracts. Not sure anyone else does. That's why there's a question)
• Consents
• StockDistributions (E.g. delivering bedsheets. Please rename. Do we need a 'request' resource too?)
• Encounters (was Admissions)
• PatientTransfers (Movement of people from one place to another. Do we need a 'request' resource too?)

Clinical Components

• AdverseReactions (GG: for me, whether it is a good idea to differentiate between Adverse Reactions and Allergies is an open question; LM: They're different things. Allergies can be supported by 0..* adverse reactions)
• AllergiesAndIntolerances
• AssessmentScales (GG: why isn't this just a general observation? EK: Do we even have "general" observations? Or is that SimpleObservations? I put it here to reflect whether we might need to explicitly model some common patterns to support consistency)
• DietOrders (was Diets) (GG: why order?)
• HealthcareActivity (covers the 'simple' administrative activities like study administrative activities, refusal to fill, most stuff that maps to Act in ClinicalStatement, etc.) (GG: oh? What kind of contents does it have? LM: Type, patient, reason, effectiveTime, etc. How else would we do this?)
• HealthConditions
• ImagingReports
• Implants (is this the implanted devices or the inplant/explant procedures or both?)
• LabOrders (GG: order/request? LM: Y)
• LabPromises (Do we need promises here? Do we need them anywhere else? Need a more business-intuitive name) (GG: if you 200 ack a request, it's accepted?; LM: Except the lab often provides detail about exactly what it plans to do. So 200 isnt sufficient. GG: a 200 response is not an empty body....; LM: In the lab model right now, "promise" is a managable artifact with its own state machine. It can be suspended, aborted, etc.)
• LabReports
• NonSurgicalServices (e.g. counselling, massage therapy, refusal to dispense?, etc.) (GG: Aggregation profile....; LM: No. This is equivalent to surgicalProcedure, but simpler. This isn't a report. This is "what was done")
• Problems (GG: how is this different to HealthConditions? EK: The official answer is probably: a condition does not necessarily need to be a problem all the time.)
• Questionnaires (GG: how is this different to assessment scale? EK: I was thinking about textual questionnaires here, with optional sections, multiple choices, the works)
• RadiationAdministrations (GG: why are these different to surgical procedures? LM: Surgical procedures don't have dosages, don't repeat every week for 3 weeks, then a week off; etc.)
• SimpleObservations (was Vitals, includes things like patient notes too) (GG: not happy with either name)
• SurgicalProcedures

Pharmacy Resources

See the linked page for a formal proposal to create the pharmacy resources.

• Administrations - record that something was actually administered to someone) (GG: what's an administration? application? Statement of intent to have the patient take medication? LM: Record that a drug was actually administered. Generally happens in hospitals, but occasionally used for things like Methadone in the community.)
• Dispenses
• Prescriptions
  • Jean: I've taken the MedicationOrDevice thing out. In all cases, we are administering, dispensing, or prescribing a product and what the actual product is tends to be irrelevant.
  • LM: They behave a bit differently. Device prescriptions generally don't have administration instructions. Treating vision prescriptions as device prescriptions could work, but we'll need a complex enough structure to properly define the "vision product".
  • Jean: See above about the Product. The CPM structure would allow for vision prescriptions as products - with the prescription being the type of lens.
• VisionDispenses (GG: uh? Seems.... random; LM: We need them in Canada. Don't think you can make them work inside a drug/device Rx. Possible candidate for realm-specific resource at least for now)
• MedicationAndDevicePromise (Need to rename this) (GG: why? Where's the request; Prescription; Also known as the "encoding" in v2. Only relevant in hospitals, but very relevant there.)
  • LM:Encoded orders are a key resource in hospital pharmacy, though not community pharmacy. However we resolve mood codes, this will have to be represented. Removing it now would be premature.
  • JD: Encoded orders are represented by Administrations by the current HL7 committee, but I'll leave it here.
  • LM: That's odd, because encoded orders also encompass what the pharmacy plans to dispense.

• MedicationProfiles (summarizes active, inactive and recently active medications, including non-prescribed medications) (GG: this is an aggregation? LM: No. It's a higher level and includes stuff that's not prescribed. However, it relates to other resources. This is one of the tricky ones)
  • Jean: This is just an aggregation of administrations (either directly entered or inferred from prescriptions/dispenses.
  • LM: Sort of. It's a summary of the medications a patient is believed to be taking or was recently taking. It includes prescribed & dispensed medications as well as "over the counter" medications, supplements and similar substances. Thus *some* of the content can be derived from the resources we've got, some not.
  • Jean: Everything you discussed is either inferred from a prescription/dispense or is stated as an Administration. So the MedicationProfile is just an aggregation of all inferred/actual administrations that a system knows about.

Public Health

• Exposures (Environmental or otherwise)
• Immunizations (GG: why isn't this an adminstration? - LM: Because they capture different stuff and the world thinks about them differently. With immunizations there's the idea of being a booster, etc. Also reason for refusal, etc.)
• PublicHealthCases (GG: Aren't these aggregations; LM: No. They'll have aggregated stuff tied to them, but you still need the base structure for the case itself.)
• PublicHealthInvestigations (GG: Aren't these aggregations; LM: No - see above)

Care Management

• ReferralRequest (The request piece without all of the supporting stuff that's in the overall Referral document) (GG: I think there's a pattern here: a request resource used to request other things, and the the other things it requests). EK: I actually tried this out once on a project where I was asked to define a "v3-ish" model for neonatology. I had an "Order" for something (with who, when) referring to an actual instance of the thing ordered. Unfortunately you need to mark this instance as being only an "example" or "prototype" of the thing you want to order, and many of its properties become meaningless. But the client (and its designers) understood that and liked it.
• CarePlans (both plan + planned activities?; LM: Presume the planned activities would be references to other resources. EK: Yeah, again: these referenced activities might need to be marked as "prototypes")
• CareLists (Medication lists, problem lists, etc.) (GG doesn't understand the difference between CarePlans and Carelists - and the lists are aggregations...?; LM: Lists are views that are maintained. User decides what's on the list and what's not)
• CareProvisions (Need to define this, differentiate from Encounter and CareCollections) (GG: don't see the difference)
• Concerns (ContSys Health Issue - Is this different from "HealthConditions"?) (GG: no, not different) EK: Or is this equivalent to "problem"? Stuck Concerns in Care Management, because this is where you flag a condition as actually being a problem, so you could make it show up in lists.

Financial

• Accounts (GG: what's an account? or perhaps, what's in scope? LM: Accounts have numbers, owners, and not much else that's currently needed)
• Coverages (insurance, government issued, etc.)
• Guarantors (could possibly be rolled into Coverage, but I’m not sure) (GG yes, an agent associated with a guarantor)
• Invoices
• InvoiceAdjudications
• Payments
• Predeterminations (also encompasses authorizations?)
• PredeterminationRequests (also encompasses authorizationRequests?) (GG: request pattern?)

Research

• ClinicalTrialDesigns
• ClinicalTrials (GG: what's the scope of this; LM: Don't understand the question. It covers the stuff that's in RCRIM)

Aggregation Profiles

GG: these are not resources

• Consultations (GG: This is an aggregation profile, not a resource)
• DischargeSummaries
• Letters
• PatientSummaries
• Notes
• TransitionRequests

Unsure

These are areas HL7 supports where it's not clear if additional resources are required

• Genetics stuff - Can this all fit under lab observation or is something more required?
• Organizers - Can this be embedded inside Document, or does it need to exist elsewhere?
• SafetyReport - Is this just another type of document grouper?
• SPL - Is Medication sufficient?

GG:

• Genetics : we'll need a resource
• organisers: that's a pattern not a resource, or it belongs in hdata; LM: I don't think it can be in HDATA. In a ClinicalDocument, we need to define the hierarchy of sections and sub-sections.
• safety report - don't know.
• SPL - it's an aggregation....

Mood Stuff

EK: Seems we identified a pattern for some moods: at least ordering could be done by using an Order resource + reference to a (prototype) resource being ordered. Same for CarePlan?

GG: right. indeed. But one lovely thing about moodCode - as much as we call hate it in practice - it marks explicitly the instance whether it is real or prospective or imaginary, without having to query for all the possible grammars that could make an act so. That's a massive outcome compared to having other resources point at it and change it's state. I suspect that a pattern for moodCodes will be a moodCode attribute. Yuck

LM: Alternative is to set it up so we can maintain one resource that is in event mood and "generate" additional resource definitions in other moods when/if we need them. Because they really should be separate resources. When I query for lab results, I shouldn't see lab orders. It'll create a bit more effort on the design side (some attributes, such as value, should be suppressed in certain moods, and we may have to revise the descriptions. Another possibility is just bite the bullet and define separate resources for request, promise, definition and criterion where we think the need justifies. And perhaps design some QA that compares the resources across mood to make sure we're consistent.

GG: need to consider the question of requests and conditions and mood codes generally

• Rene: in SMIRFs we required fixed moodCodes. Suggests not to have moodCode in a resource, or at least not anywhere in the wire format.

• GG: Absolutely agree. But it might not be so easy - see comments at bottom. Would you have a SMIRF for every moodcode?

• EK: Yes. The reason was that the purpose, features and interpretation of a SMIRF should be clear and easy to document on a SMIRF-by-SMIRF basis. This is the same for resources. Having a SMIRF/Resource with a moodCode attribute would make this very hard: interpetation of much of the other attributes and even the description of the Resource would change, depending on this moodCode. I know that moodCode is not really a "variable" but a static attribute acting as a classifier, but hey, this is something many non-hl7v3ers have a hard time grasping. Therefore I did not want a SMIRF with a non-fixed moodcode. Different moodCode->different SMIRF->different set of documentation

• JD: I think, after thinking about it for 15 minutes, that we'll have to go with EK's idea of different resource for different mood. So we'll have PrescriptionRequest, PrescriptionPromise, PrescriptionEvent, etc. I agree with Lloyd that we'll need a way to harmonize the different mood resources to ensure they're consistent. Perhaps a generic Prescription resource and then a constrained resource for each mood?

• GG: why do we need things? What's the cycle? Instruction.... request for prescription....record of prescription. What's all these other things?

• • JD: Prescription was probably a bad example. There would be a Definition, then the request, and then the event. But the Lab domain provides us with more - the definition of the lab test (used in clinical trials), the lab order (what I want you to do), the Lab promise (what I tell you I'm going to do), and the Lab event (what actually occurred). At this time, I'm not sure what would be different other than the conformance profile - some attributes would differ in cardinality or optionality depending on the "mood".

• LM: I'd say we have Prescription, Dispense and ActiveMedication for community. For hospitals, we'll add on PrescriptionEncoding (aka Promise) and DrugAdministration. Flow is: Prescription, then Encoding, then Dispense, then Administration. ActiveMedication stands alone, though it can draw on the others sometimes depending on how it's designed. We still need to think about having PrescriptionDefinitions for things like clinical trials and protocols, but we can worry about those later.

• • GG: is lab event different to lab report? what goes in a definition other than a list of test codes?

• • LM: Lab event and lab report are synonymous. A definition includes things like criteria for when it can occur (must fast 24 hours in advance, can't be taking X drugs, etc.). For things like clinical trials, may also include component relationships and/or timing expectations (e.g. test X involves doing X1 daily, X2 hourly and X3 once).

• • JD: I have no idea what ActiveMedication would be. And you're conflating workflow with resource moods. A Prescription is a different resource from a Dispense and an Administration. We should stick to the Lab examples as they provide real-world analogies of the mood concept. :)

• • LM: Huh? Agree a prescription and a dispense and an administration are different resources. A prescription encoding is a different resource too. In v3 terms, it's a promise. In v2 terms it's an RXE (as opposed to RXO, RXD and RXG). It's very real-world. "Active medication" is a summary of what patient's the patient is taking or has recently taken. It's derived from prescription records, dispense records and "non-prescribed medication" records. It's a common need, and it's going to be really unfortunate if the only way an application can get that view is to do separate queries on each of the resources. I suspect we can make it work as an aggregation, though there's some summarizing involved that we'll have to figure out.