Refer to FHIR Resource Considerations for guidance on criteria for resources.

This page provides a list of candidate resource topics. It is for brainstorming and for getting a sense of what resources might eventually exist. The presence or absence of a particular resource on this list in no way commits HL7 to action one way or another.


Resource List

Note: A more up-to-date list of resources expected in the near term is maintained by the FMG here[Tracking Sheet.xlsx]

Infrastructure

Stakeholder Resources

File:Stakeholders.png

Other Participant Resources

Administrative Resources

Clinical Components

Pharmacy Resources

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

Public Health

Care Management

Financial

Research

Aggregation Profiles

GG: these are not resources

Unsure

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

GG:

HG: No SPL is a special kind of document that tells you the specification of a medicine. Maybe its an organiser?

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

Devices Discussion

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

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.