Talk:FHIR general issues (old)

How do we handle versioning (and retrieving history)?

• discussion with Ewout leans toward moving the metadata - create/update time and version number - out of the resource. ETags in HTTP, handled explicitly elsewhere. See Data, records and versions in RFH for a full discussion
• LM: we'd still need to talk about how to provide a list of the versions that exist for a given resource instance so you can query them. Ideally when you bring back a resource it would include a list of versions and the minimal metadata on the change - type of change, why, who and when.
• LM: Retrieving history now covered

How do we handle templating?

Templating means defining and referencing additional constraints on how content in a resource is populated for a particular 'kind' of item. This is distinct from a profile which applies to all uses of a particular resource or aggregation

• Jean: I have yet to see an actual physical template, even though I keep sitting in Templates in the hopes of seeing one. If someone could show me what a physical template for a resource would likely look like, I think we could answer this question better.
• There's three implementations I've seen - the UK MIM approach static model approach, the SD/Lantana schematron one, and the GE one, though they're a bit backwards in bringing that one forwards
• Each is quite different, and approaches the template spec from a different direction. I've never seen anyone use the template spec itself.
• The problem is that a template is actually doing a two different things
  • making a set of rules about how features are used (i.e. a conformance statement) (RFH includes one of these)
  • explaining what the parts mean in a given context
• any individual template is doing a bit of both. The balance between the two is variable
• LM: I'm not a big fan of "explaining what the parts mean". That should be clear from the instance. There's a slight difference between templates and profiles in that a profile applies to everywhere a resource is used, or in the context of a particular aggregation. A template applies to an instance only when conveying a particular type of data.
• GG: what the parts mean in a particular context. Here I have a Result group, and a list of results. how are they used - what do they mean - in the context of a micro result?
• LM: "What are you allowed to send?", sure. "What do they mean?", no. The "What do they mean?" has to be fully covered by the instance. I don't want templates messing with ontology mappings, which is what would happen if templates were allowed to affect meaning. I accept that changing meaning may happen in some v3 scenarios (particularly in badly defined CDA models), but there's no reason to allow support for that in RFH.
• GG: Not sure what to say. Go read any DMIM or RMIM or template. It defines "what the elements" mean in a particular context of use. It's not that they change the meaning, but that they narrow it - except who are we kidding; the fact that they redefine meanings is the dirty secret of v3 - it happens everywhere. But putting that aside, they narrow the meaning - that's what they *do*
• LM: The question is whether the instance would have the same interpretation whether the template was declared or not. If the answer is "no", then it's a bad template. If the answer is "yes", then it's fine. Constraining meaning is fine. Supplementing meaning is not fine.
• right, supplanting happens a lot. but putting that aside, constraining or narrowing is the go, and it's important. When we talk about templating in RFH, are talking about one or the other or both (setting rules, explaining meaning)?
• Templating is now reasonably well handled by Profile. Further discussion to happen there

How do we manage resource identification and referencing across repositories?

E.g. One application on one server manages "lab", another application on a different server manages "prescriptions", and you're creating a document aggregation that lives on yet another server that needs to reference resources from the other two.

• GG: I assumed that the question of where resources lived is managed by configuration rather than explicitly, since these things always change
• LM: You're making the assumptions that a given system will only references resources of a given type from a single source, but that's not necessarily a safe assumption either. I think we need to handle resource references with local ids and remote ids. Remote ids would be the full URL. Local ids would strip off the base.
• GG: No, that might be true. But how would a remote id work, given it might be inlined in an aggregation? And as it is, the identifier may be a URL or a simple id, see here: http://www.healthintersections.com.au/rfh/http.htm (base URL)
• LM: That's not clear from the examples, though after digging I do see that the root can be a URI. Not sure I understand your question about inlining a remote resource. You'd inline it and include the id which would be a foreign reference.

• GG: if you put a resource in an aggregation, and it refers to a resource at a URL - do you mean to refer to the one in the aggregation or not?

• LM: So resource A references resource B, both included inline in an aggregation? Given that the URL would be declared on B, it'd be pretty easy for an application to realize that it already has the resource and doesn't need to retrieve it. However, technically, all references are always to the resource source.

• yes, so we need to make some rules about the behaviour of resource references and ids

• Now well defined in Resource References

Need to add support for choices

• GG: sort of have them now (observation values, resource links). why more?
• LM: Because sometimes you'll need a choice that isn't a resource. For example, if you're prescribing a compound, you're unlikely to store the compound as its own resource. (When it comes to dermatology, they'd freak at the idea someone else could prescribe "their" compound.) So sometimes resource definitions (or portions of them) will need to occur in-line. Organization is another one. Why create a full-blown resource when often all you need is a name?
• I think much of your argument is irrelevant, but agree that moving things out to resources to have choices is not as good idea. What specific cases do you have in mind?
• LM: I didn't, so I'll come up with one now :> "Reason for prescription could be a condition (reference to a resource) or an ad-hoc reason such as "prophylaxis".
• LM: Solve this by allowing both and adding a constraint that says you can only have one or the other (if in fact that's the rule you want)

What resources reference what?

I'm not sure exactly what this question means. It came up at the RIMBAA discussion and I was partially tuned out. However Grahame said it was a good question and Ewout nodded his head, so I figured I'd write it down . . . :>

• EK: Must be the discussion with Ann. We agreed the next day that we could have references to resources that are like "indentified/confirmable" CMETs now, so include some of the referenced data. Also avoids unneccessary querying of resources just to get someone's first name. Within a packaged assembly, references should use XML id/idref.

• GG: I sure didn't agree to that! That's leaning over a cliff of insanity to make something easy for some and harder for everybody. In a restful environment, you want to query resources. In an aggregate, why have multiple different ways of doing things - useless syntactical variation without non-syntactical value?

• LM: I think it's now 3 against 1 . . . ;> Actually, this *isn't* Anne's thing. That came up later. I *think* this is a directionality question. For example, Patient might reference Person, but you could also have Person reference Patient. We need to figure out which direction references should go in. (Or how to manage conflicts/misalignment if we allow bi-directional.) I've added Anne's issue below

• GG: Ewout and I discussed this in San Diego. I first modeled references as separate to content. But the references have a context in where they're from. So references are directional. I have a diagram we drew and will try to reproduce here later. Where the references are actually peer-to-peer, you either make them in both places, or create a new resource for them. Will post more info.

• LM: Asked & answered

What does resource "inheritance" mean for resources?

The proposal shows the idea of inheritance from "Base resource". Seeing as Base resource is abstract, that doesn't really matter. But I'm not clear on if/how this will work for other resources. If you query an ancestor resource, do you get back all child resources? Can you update an ancestor resource and add attributes associated with a particular child type? What happens if the resources are maintained on separate systems?

• GG: the definitions define the notions of subsumption between resource elements and different resources. But this knowledge does not surface at the implementation level
• LM: So what does it accomplish, given that the definitions can change at each level anyhow?
• GG: it means you can reason with the assertions of equality.
• LM: You're going to have to expand on that a bit for me . . . :>
• LM: We're not really doing inheritance. Inheritence in the UML diagrams is just a convention for identifying the "root" element