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

Resource List

• Link = Point to existing resource definition
• Bold = Resource expected to be built - target committee identified in brackets
• Italic = Resource concept that will likely be excluded (document reason)

Infrastructure

• Alert (InM?) (Covers DetectedIssue)
• AlertManagement (InM?) (Covers DetectedIssueManagement?) (GG: Alerts? or management of something?)
• ChangeRecord (InM?) (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)
• ServiceMasterFile: A master-file will be an aggregation. However, we'll need to define specific resources to appear inside a master file. Will need to figure out granularity
• (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

• Agent (PA) : A person acting on behalf of an organisation (AssignedPerson). This name isn't intuitive. Provider might be better
  • Provider (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.)
• Department: Subsumed into Organization
• Employee: Not clear we have a use-case for this. Does anyone use HL7 for HR?
• Patient (PA) (EK: in my SMIRFS, this resource included validity verifications and administrative observations)
• Person (PA) Principle difference between patient and person is what things can point to it
• Organization (PA)
• Team (PA) (EK: this is a group of people. Better name than "Group", which could group anything )
• PersonalRelationship - 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.
  • EK: True. Though it might be illogical to place this nested data in one of the related persons as opposed to the other, so then a separate resource pointing to both participants might conceptually make more sense.

Other Participant Resources

• Animal (PA) (GG: Aren't these patients? LM: Not always. Can also be work animals, subjects of clinical trials, other things)
• AccessPort :Not sure we'd track this independently (tubes in and out of patients)
• SoftwareApplication (Not sure this needs to be distinct from Devices) (GG: devices)
• DeliveryLocation (PA) - (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)
• InventoryItem (Stuff that can be shipped) (Devices and materials can be shipped? LM: Y. bedsheets, etc.)
• Material (Need to hold cosmetics and other stuff that's not necessarily specimens or devices)
• Place (PA) (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).
• Product - Covered by Material, Device, Medication
• Device
• Medication (Pharmacy)
• Monograph : Can't this just be handled as Document? (moved from Pharmacy section)
• SchedulableResource (Items that can be scheduled not elsewhere covered)
• Specimen

Administrative Resources

• Appointment (PA)
• AppointmentRequest (PA)
• AccessRestriction (Security? InM?) (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)
• CareCollection - This should be handled as an aggregation
• InterestOfCare (the notion that some clinical care provider has an ongoing interest in the care provided, such as a registered GP) LM: Don't understand)
• Contract - (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)
• Consent (Security? InM?)
• StockDistributions (E.g. delivering bedsheets. Please rename. Do we need a 'request' resource too?)
• Encounter (PA) (was Admission)
• PatientTransfer (PC) (Movement of people from one place to another. Do we need a 'request' resource too?)

Clinical Components

• AdverseReaction (PC) (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)
• AllergyOrIntolerance (PC)
• AssessmentScale (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)
• DietOrder (OO) (was Diet) (GG: why order?)
• HealthCondition (PC) (aka Problem)
• ImagingReport (II)
• Implant (is this the implanted devices or the inplant/explant procedures or both?)
• LabOrder (OO) (GG: order/request? LM: Y)
• LabPromise (OO) (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.)
• LabReport (OO)
• HealthcareActivity (PC) (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?)
• NonSurgicalService (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") Covered by HealthcareActivity or Procedure
• Questionnaire (GG: how is this different to assessment scale? EK: I was thinking about textual questionnaires here, with optional sections, multiple choices, the works)
• RadiationAdministration (OO) (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.)
• SimpleObservation (OO) (was Vitals, includes things like patient notes too) (GG: not happy with either name)
• Visit or Examination - (gb -Whatever happens when I go to my primary and he asks questions before poking and prodding me and ordering others to do vile things to me. Vitals go here, and should also cover inpatient visits while doing rounds.)
• Procedure (PC) (surgical and otherwise)

Pharmacy Resources

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

• Administration (Pharmacy) - 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.)
• Dispense (Pharmacy)
• Prescription (Pharmacy)
  • 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.
• VisionDispense (Pharmacy) (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 (Pharmacy) (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.
• ActiveMedicationProfile (Pharmacy): This is an aggregation with groupers that split content into active, recently active, etc.
• MedicationStatement (Pharmacy): Reflects an assertion that a patient is taking a given medication. This is distinct from a record of an administration or a prescription.

Public Health

• Exposure (PHER) (Environmental or otherwise - Will need to partition from MedicationStatement, Immunization, etc.)
• Immunization (PHER) (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.)
• PublicHealthCase (PHER) (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.)
• PublicHealthInvestigation (PHER) (GG: Aren't these aggregations; LM: No - see above)

Care Management

• ReferralRequest (PC) (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.
• CarePlan (PC) (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")
• CareList (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)
  • These will be handled as aggregation resources
• CareProvision (Need to define this, differentiate from Encounter and CareCollections) (GG: don't see the difference) - probably not necessary
• Concern (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. Handled as HealthCondition

Financial

• Account (FM) (GG: what's an account? or perhaps, what's in scope? LM: Accounts have numbers, owners, and not much else that's currently needed)
• Coverage (FM) (insurance, government issued, etc.)
• Guarantor (FM) (could possibly be rolled into Coverage, but I’m not sure) (GG yes, an agent associated with a guarantor)
• Invoice (FM)
• InvoiceAdjudication (FM)
• Payment (FM)
• Predetermination (FM) (also encompasses authorizations?)
• PredeterminationRequest (FM) (also encompasses authorizationRequests?) (GG: request pattern? - yes)

Research

• ClinicalTrialDesign (RCRIM)
• ClinicalTrial (RCRIM) (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

• Consultation (PC) (GG: This is an aggregation profile, not a resource)
• DischargeSummary (PC)
• Letter (PC)
• PatientSummary (PC)
• Note (PC)
• TransitionRequest (PC)

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:

• GeneticObservation : 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.

Devices Discussion

Discussion in devices 17-may 2012:Discussion indicated that there would likely be 2 resources:

• DeviceDescription - describes the existence of a device and it's operational capabilities, along with links to the profiles it supports
• DeviceEventData - a provision of actual data make available by the device

These resources are used with profiles to describe how devices operate, and to interact with them. Names and contents subject to further discussion and review. Devices to consider the implications of this further.