FHIR general issues (old)

These are issues that need resolution before FHIR can be "complete". (We should probably make these into separate pages all grouped with this page as a "category" grouper, but we'll wait to get them fleshed out a bit before doing that.

Do we need distributed commit across resources (or even repositories)?

• related: https://plus.google.com/u/0/106957993402864061713/posts/KqQsSbGoGUq

Fix identifier type codes

The existing proposed vocabulary is a total mess. A complete vocabulary would go into the 10s of thousands and is untennable. We need to revisit this structure

• GG: yes, but we need something. It's not just for humans either - it drives selection of an identifier for filling out other content models (forms, v2 messages, etc)
• LM: However, in v2, there's just a random grab-bag of ids. We don't need to (and shouldn't) replicate that approach in RFH. It may be we will need typing in a few places, but if we do, we need to set it up so that the set of types allowed is constrained in that context rather than having a set of codes that tries (and fails) to cover everything. Also, v2 had minimal reliance on (or presence of) registered assigning authority ids. So the list of v2 identifier types was really meant to be combined with the jurisdiction or facility to create an "on-the-fly" assigning authority. We don't need to do that in RFH because assigningAuthority is mandatory and the set of assigning authorities for most important identifiers is already registered in one place.
• GG: we need typing over simple IDs in a few places. And the typing has one primary function: so that people know which id to put where in a form or a v2 message. The problem that RFH is trying to solve here is that in some cases, you might know the type without knowing the assigning authority i.e. driver's license) and in other cases, you might know the assigning authority id, but have no idea how to resolve that to a type.
• LM: Ouch. You're planning to allow the assigning authority to be missing?? I'm really opposed to that idea. If knowing the type is important enough to make computable decisions based on it, then you should have a list of all the possible relevant assigning authorities. (There's only one place you need to look for them.) If you're not using it for computation, then fill in the textual label for the assigning authority and be done with it. IIF we need to resolve assigningAuthority to type and there's no reasonable way to determine type from context or a parallel attribute, then we can look at allowing it in the datatype, or possibly supplementing the OID registry to allow it to be derived from assigningAuthority. Heck, we could even make assigningAuthorities into resources so we can tack on the desired metadata.

• GG: no, go read the data type first (HumanId). If the system is missing, it's got a dataAbsenceReason. And there's *no* place you can look for all possible relevant authorities, and even when we provide an API to the OID registry, that still won't tell you what type of id it is. And there are cases where you know the type and not the assigning authority. The base identifier is the same as II - only system and identifier. We are talking about the HumanId type, which corresponds to the v3 design pattern (can't find the link)

• LM: All "public" authorities will be in the HL7 OID registry. We could supplement the OID registry to declare the type if we think that's relevant/necessary. I'd like a use-case for where authority won't be available but id type is necessary for computation and can't be determined from the context in which the id is used. I've looked at humanId again and now realize you don't even *have* an assigningAuthority, meaning the identifier is totally useless in terms of actual identification. Also, you've dropped "scope" from identifier

• You're wrong about HumanId because the core identifier is an Identifier, which has the root. I think that's what you're referring to. It's very common to find that you have an id that has a type, but you don't know the root, or even if you know the root, you don't recognise it. And the Hl7 OID registry doesn't help you resolve the type. And I am against registering every identifier source - there's millions of them; every feeder system to a national EHR is going to have a handful of them, and your interests in them are * using them as a system identifier (Identifier type) and * using them as a human identifier (this item goes here on your form). Registering these identifiers in the OID registry is an exercise in futility

How do we support human readability for resource references?

Originally raised by Anne in San Diego. The basic concern was that for a human (developer, tester, whomever), linking by resource id is a huge PIA, particularly for lightweight things like providers, organizations, drugs, etc. where you may only have a name, or possibly a name + id. Having bare GUIDs strung all over makes Visual inspection of the instance darn near impossible. Obviously RFH wouldn't be as bad as something like XMI, but it would hit the same problem. The way she expressed her issue was an objection to a "flat" serialization mechanism (where all resources are sent as siblings). Instead, she wanted all resources nested, even if they repeated (with an obvious exception for resources that recursed).

• LM: Ewout and I were talking and discussed one possible option, which is to allow a reference to a resource but include the "mandatory" or "required" elements at the location doing the reference. If these were the only elements required, then you'd simply do resource definition in-line (even if the same resource was referenced multiple times in the instance). As well, you could theoretically do this *without* defining a resource in circumstances where maintaining the referenced item as a resource didn't make sense. (E.g. an organization where you only know the name and may not care about them ever again.)

• Rene: Hmm. That would raise all sorts of issues related to potential differences between the data available at the location doing the reference versus the resource being referenced. In this type of setting human readibility is not a prime design feature. If you desperately want human readability, add something in a textual_description associated with the reference (both at the location doing the reference), but do not populate any stuctured attributes (those are not for human readability).

• LM: The content would have to be from the resource source. If we didn't have a resource reference, it would only be if there was no resource at all

• GG: weird to have developers arguing for something while a bureaucrat argues against it on behalf of the developers. I don't like by reference, and I don't like duplication. And I don't like needless syntactical optionality. More investigation needed.

Misc Issues

• Should DataAbsentReason be DataAbsenceReason?
  • LM: Why?