The Resource With No Name

Background

FHIR allows extensibility within resources to cater for the things that don't go in the core resource model. But these extensions are constrained to be within the scope of the resource. i.e. you can't add a whole medical record to person.

Exactly the same argument around extensibility applies to resources themselves - we need to limit the overall number of resources for practical reasons - the number of use cases is large and potentially unlimited. So how does extensibility apply to resources themselves?

Enter The Resource With No Name. [[1]]

This is a resource that has no particular structure or meaning, just a code to tell you what it is, and extensions for the actual content. Well, maybe. Such a beast would be most useful and also must dangerous. Perhaps too dangerous to define - we don't it to turn on us...

Governance

We don't want just create an open bucket that all the worst problems get pushed into, and that's such a fount of misuse that no one can do anything with it, and no one can do anything without encountering it either. So the fundamental question is what governance does this thing need around it? Any contents it have must be tightly linked to that governance.

The other thing to note is that the governance around the extensibility that does exist in FHIR has been the most hotly debated aspect of FHIR, and it's not over yet. This has the potential to be just as much fun.

ideas

In the section place ideas for how to govern and/or design this resource. We're looking for the sweet spot: the most balance between functionality and danger.

• GG: use the backbone of the openEHR RM to provide basic semantics (Observation, Action, Evaluation, Instruction, with their basic properties)
  • Well, arguing for the openEHR RM could bring its own issues
• LM: If we get the semantic RIM modelling working, it should be possible to test that a given resource definition doesn't overlap with any of the other defined resources. However, that's dependent on who-ever creates the custom resource actually defining the RIM semantics accurately, which may be a bit too much to ask.
• LM: One possibility is to say that, in order to be FHIR conformant, the "code" that defines what kind of resource it is must come from an HL7-defined vocabulary. That allows us to at least control the definition and ensure that it doesn't collide with other resources while not requiring HL7 to publish resources for stuff that's really on the edge. (And if over time the use of it becomes common enough, we can always publish a real resource for it.)
• EK: If there's a ClinicalStatement resource, this would already be almost as powerful (and almost as dangerous) as the Resource With No Name. Many of these might also be Questionnaire resources or some as yet undefined AdministrativeEvent resource. All in all, I would venture that any usecase for a RWNN can always be mapped to some of these more generic "top level" resources. Which is almost the same as what GG is saying when adoption the very general openEHR classes as resources.