Difference between revisions of "FHIR general issues (old)"

Latest revision as of 21:53, 7 September 2012

Back to FHIR

Back to FHIR discussions / active discussions

This page contains discussion about issues and considerations related to HL7's FHIR specification. When adding content to a page, be sure to uncomment the "Active" category if it is commented (surrounded by ) so that others can notice it and participate too.

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

Need to decide how we're going to express ontology mappings to the RIM

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?

@@ Line 2: / Line 2: @@
 [[Category:Active FHIR Discussion]]
-These are issues that need resolution before RFH 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.
+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.
-==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.
-==How do we handle "definitions" and possibly other moods?==
-We're going to need definitions of most stuff for ClinicalTrials, and at least some things for various masterfiles (lab, drug protocols, etc.)  Also, we'll need "requests" for many things, promises for some of them, etc.  We should handle this consistently, but still in a way "intuitive" to implementers.
-* Jean: Do we really need this?  Mood is one of the sillier things that HL7 v3 implementers have to deal with.  And in almost all cases, the mood is fixed and determined by the behaviour being requested.  On the NCI caEHR project, we actually ignored mood and implied it by the service being called.  So if I am querying for a resource, the resource mood is EVN or DEF and I don't really care.
-* LM: Agree we should avoid introducing moodCode if at all possible.  I don't think we can avoid having resources for requests, definitions or promises though (where actually needed).  From a business perspective, I think we need to handle these as distinct resources.  Because the constraints are going to be different in the different moods and squishing multiple moods into a single resource is going to confuse the heck out of people.
-* GG: I've been thinking that this is furphy. moodCode is a lower level issue driven by modeling at a particular level. What kind of resource would have a mood, and where the mood would not change it's content? I think we have an ordering cycle that needs a general pattern. And we have care plan that needs a pattern. I don't know whether the pattern is the implementation yet
-* Jean: We've got this discussion going on in two places.  I think we're heading towards a solution that there is no 'moodCode' attribute.  But we will need to allow resources to support different conformance statements based on how the resource is being used.  The outstanding problem as I see it, is if the use/definition of an attribute changes depend on the use of the resource.  As an example, the formCode on a Prescription could be a list of allowed forms when being sent as a definition but would be restricted to a single repetition and indicate what form was actually prescribed when sent as a request or event.  (Contrived but I think it gets the point).  I'd hate to see "if used as X, then means Y" in the ontology.
-* LM: I disagree.  I think we need totally separate resources for different moods.  One for prescription, one for promise, one for dispense, one for administration.  Trying to cram these into a single resource would be a mistake.  It results in yucky complexity in terms of conformance profiles, and is confusing to business experts and implementers.  And the only reason to do it is to avoid the "overhead" of defining the same structures multiple times.  In practice, they're rarely the same structures.  The detail required to encode dosage in a prescription is often not the same as required on a dispense.  There are attributes on dispenses that aren't on prescriptions and vice versa.
-* Jean: Well, your listing isn't one resource in different moods - it's three different resources plus the promise.  An administration has completely different attributes from a dispense.  So that's not the problem.  The problem is how to handle the ordering of a dispense, the promise to dispense something, and the statement of what actually was dispensed.  I think that within that set of moods, the complexity is actually quite smaller.  I suspect we'll have to try it to see though.
-* LM: Dispense order and dispense event are quite different.  Defining one resource definition for both would be problematic.  Dispense order and dispense promise are much closer.  However, there's still an issue of how to keep them distinct.  We could take the approach of saying that all promises are actually "internal" orders.  Thus, you could have one system that creates an order, and another system that creates a more "encoded" version of that resource as its own internal order, using the same underlying resource definition.  So long as we allow orders to fulfil orders, that can work.  But order, definition and event will need to be separate resource types.
-* GG: Where do we actually need "definition" on a resource? - I very doubt it's ever been used anywhere
-* LM: Canada uses DEF mood for SBADM to define allowed/recommended dosages as part of a drug monograph.  RCRIM uses DEF to define allowed acts as part of a clinical trial design.
-* Right, but are these *resources*? I don't think so
-==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)?
-==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
 ==Do we need distributed commit across resources (or even repositories)?==
@@ Line 70: / Line 22: @@
 * 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
-==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".
 ==Need to decide how we're going to express ontology mappings to the RIM==
-==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.
 ==How do we support human readability for resource references?==
@@ Line 102: / Line 36: @@
 *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.
-==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 . . . :>
 == Misc Issues ==
 * Should DataAbsentReason be DataAbsenceReason?
+** LM: Why?
-== Lloyd's top 10 ==
-#[[Extensibility_Page#What's_the_context_for_determining_80%?|Context of the 80%]]
-#[[Extensibility_Page#Schema_compatibility_of_future_versions|Do we change wire format when moving extensions to core?]]
-#[[Extensibility_Page#Extensions_that_can_apply_to_multiple_paths|Extensions that apply to multiple resources]]
-#[[Xml_Page#Ontology|What do we mean by 'FHIR is an Ontology'?]]
-#[[Extensibility_Page#Vetting|Vetting - I'm assuming it's happening, but I'm not sure you've ever agreed]]
-#[[Extensibility_Page#What_are_the_formal_semantics_of_'must_understand'|Semantics of 'must understand']]
-#[[Constraint_Page|Details of conformance profiles]]
-#[[RFH_Issues#Need_to_add_support_for_choices|How will we support choices]]
-#[[Xml_Page#Mappings|How are mappings maintained and exposed?]]
-#[[Extensibility_Page#Extension_Registry|How will the Extension Registry work?]]

Difference between revisions of "FHIR general issues (old)"

Latest revision as of 21:53, 7 September 2012

Contents

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

Fix identifier type codes

Need to decide how we're going to express ontology mappings to the RIM

How do we support human readability for resource references?

Misc Issues

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

groups

meetings

general

Tools