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 most dangerous. Perhaps too dangerous to define - we don't want 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.
  • LM: I would be hugely opposed to introducing a ClinicalStatement resource or anything like it. That's the antithesis of what FHIR is about. The equivalent of ClinicalStatement in FHIR is "Any Resource". If you want to send a prescription, you send a Prescription resource. If you want to sent a lab result, you send a LabResult resource. It's possible that some of the more esoteric users of ClinicalStatement could be satisfied by the ResourceWithNoName, but at least we'd have governance control of them and could define a vocabulary for them and try to ensure non-collision with existing resources.
  • EK: True. I was not thinking about a big CS with containment. But we might need the top-level things like Observation, Procedure etc, with a set of flexible semantic links between them to specify cause, reason, the like.
  • LM: What use-cases did you have in mind? I would expect that we'd have resources for procedure, observation, etc. And they'd have the linkages that fell within the 80%. No more would be needed. Where things start getting messy is when we look at the planning and criterion/decision support aspects. That's when you tend to have tangled nests of relationships. But I think the solution there is resources specific to specifying care plans and decision support protocols rather than creating a generic CS structure. I.e. Drive from the use-cases, not the patterns.