This wiki has undergone a migration to Confluence found Here

FHIR Resource Types

From HL7Wiki
Jump to navigation Jump to search

(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.)



  • Resources should have a clear boundary; one that matches one or more logical transaction scopes
  • Resources should differ from each other in meaning, not just in usage (e.g., each different way to use a lab report should not result in a different resource)
  • Resources need to have a natural identity
  • Resources should be very common and used in many different business transactions
  • Resources should not be specific or detailed enough to preclude support for a wide range of business transactions
  • Resources should be mutually exclusive
  • Resources should use other resources, but they should be more than just compositions of other resources; each resource should introduce novel content
  • Resources should be organized into a logical framework based on the commonality of the resource and what it links to (see resource framework below)
  • Resources should be large enough to provide meaningful context; resources that contain only a few attributes are likely too small to provide meaningful business value

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 Governance

  • Resource governance should be commensurate with the degree of commonality; the more more common a resource is, the more stringent the governance needs to be

Resource Framework

The following framework provides a guide for what to consider resources and what to consider profiles. Note that this is a framework. It is meant to be used as a starting point and as a source of reference and guidance. It is not a set of stated requirements.


The resource framework is derived from the Information Organization Framework presented at the Health Informatics Conference in 2011 (reference forthcoming). Contact Bo Dagnall at for more details.


  • Healthcare domain large and complex – need to modularize
  • Framework Principles
    • Predictive, not prescriptive - use the framework to predict what is a resource or profile, not to dictate
    • Separation of Concerns – seperate context-neutral from context-specific resources / profiles and optimize for a defined and dedicated purpose
    • Reuse - design resources with reuse in mind based on the commonality of the resource
  • Benefits
    • Organize and manage health domains - the framework provides a basis for decomposition and modularity
    • Identify common bits - the framework teases out the common areas from the less common areas
    • Prioritize standardization work - the framework provides a structure for determining priorities and delegating work
    • Assign governance levels - the framework separates the areas needing the most stringent and universal governance from those that require more context-specific governance

First "Separation of Concerns"

The first separation of concerns is to seperate information models from terminology and instances of information artifacts. Within information models, it is important to distinguish the "Business Models" from the "Usage Models" (both of which are constrained by the Reference Model). Business models model that static structures that represent the data elements relevant to the business of healthcare. To the extent possible, business models should be usage agnostic focusing more on the core data elements and less on the "business objects" that implement the core data elements. With medications for example, the business model describes the data elements that make up a drug (including ingredients, therapeutic classes, dosage, routes, etc.), relationships that a drug has with other data elements (such as an allergy), and the basic acts associated with a drug (e.g., dispensing, administration, etc.). The usage models will describe the contents and structures of the business objects that use a drug such as a prescription, an administration record, a medication profile, etc.

[image here]

Second "Separation of Concerns"

The next decomposition introduced by the framework is to introduce layers within the business and usage models. The layers are stacked based on their degree of commonality and/or their degree of reuse with the top layers ("Base Structures") being more common than the layers beneath them ("Extended Structures").

The business model is decomposed into four layers:

  • Attribution - The who, where and when aspects of an information construct. There areas are ubiquitous and represent the most common aspects of the business model.
  • Core Business - The clinical and adminstrative components that are used in nearly every healthcare transaction.
  • Specializes Business - The clinical specialties that use and extend the Core Business entities in a context-specific manner
  • Care Delivery Setting - The data elements that are often added to business areas to deliver care in different care settings (e.g., the unique data elements required when delivering cardiac care in a pediatric setting as opposed to the intensive care unit).

The usage model is decomposed into two layers:

  • Core Compositions - The base or generic models that underpin most business transactions such as a generic order template or a summary note
  • Implementable Compositions - The compositions that extend and contextualize the core compositions such as when implementing a lab order an extension of the generic base order.

The general pattern is that the Implementable Compositions will reference or extend both the Core Compositions and the Extended Structures from the Business Model. The Core Compositions will reference or extend the Base Structures from the Business Model. Data structures within layers of the business model or usage model will reference or extend each other provided that they reference data structures in the same or higher layers (i.e., more common). See the Rules and Patterns section below for more details.

Layers of the Information Organization Framework


Third "Separation of Concerns"

Within each layer, further decomposition is required to manage the breadth and complexity of health information. The framework introduces the concepts of domains as logical packages of data elements within the Business Model. Each domain represents a model fragment that is a portion of the overall model. In this regard, a domain is a view into the larger model based on the common groupings of data elements within healthcare. Many of the domains align with clinical departments or care settings, but the alignment is not meant to be prescriptive.

Domains are not as relevant and do not carry the same meaning in the Usage Model. Instead, the Usage Model is decomposed into a heirarchy of compositions.

Business Model Domains

Note that the domains in the layers of the business model shown below are a representative, but not necessarily comprehensive set of domains. Also, the domains provided are meant to provide a starting point and can be adjusted as needed based on the requirements, input from subject matter experts and/or as a result of modeling or governance activities.

[image here]

Usage Model Compositions

The heirarchy of compositions shown below are meant to provide a representative and illustrative starting point. Modifications and additions to this set of compositions is likely.

[image here]

Identifying Resources and Profiles

Although this framework was not developed for FHIR specifically, it is applicable to FHIR. This is because both the framework and FHIR recognize that there are inherent and variable degrees of commonality within healthcare data. Information modeling should reflect the distinction between context-neutral and context-specific data structures. The diagram below uses the framework to highlight the layers, domains and compositions recommended for consideration as FHIR resources and profiles.

The framework identifies three categories of resources: 1. Attribution resources (from the Attribution layer of the Business Model) 2. Core Business resources (from the Core Business layer of the Business Model) 3. Core Compositions (from the Core Compositions layer of the Usage Model)

The framework identifies three categories of profiles: 1. Specialized profiles (from the Specialized Business layer of the Business Model) 2. Care Delivery Setting profiles (from the the Care Delivery Setting layer of the Business Model) 3. Implementable Compositions (from the Implementable Compositions layer of the Usage Model)

[image here]

Rules and Patterns

  • Resources
    • Resources can reference other resources as long as the referenced resource is in the same or higher layer of the Business or Usage Model
    • Core Composition resources from the Usage Model should only reference resources from the Base Structures portion of the Business Model (i.e., Attribution and Core Business resources)
  • Profiles
    • Profiles can reference AND extend profiles as long as the referenced profile is in the same or higher layer of the Business or Usage Model
    • Extended Structure profiles from the Business Model (i.e., Specialized Business and Care Delivery Setting profiles) can reference AND extend resources from the Base Structures portion of the Business Model (i.e., Attribution and Core Business resources)
    • Implementable Composition profiles from the Usage Model can reference AND extend Core Composition resources from the Usage Model
    • Implementable Composition profiles from the Usage MOdel should only reference AND extend profiles from the Extended Structures portion of the Business Model (i.e., Specialized Business and Care Delivery Setting profiles)

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)


  • 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


  • 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)


  • 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)


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?


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