FHIR intro and background at HL7 Germany 2014

Editor's Notes

• #9: It’s been said before by the “wise” Steve Ballmer….”developers, developers, developers”….
• #10: They probably craft something themselves We want HL7 to have an answer to these. If we don’t => someone else will do it and we will lose credibility. You could do it using v3, but not solely based on the downloadable UV-version. And probably not on some country-specific Implementation Guide either (different focus, priorities)
• #16: Readily useable, contain “the 80%” (What’s the 80%...what’s maximum reuse? That’s HL7’s core business!) Independent of context, fixed defined behaviour and meaning Can reference each other Units of exchange – suggests units of storage for implementers Addressed through HTTP or other methods
• #19: Even when you think your target will understand all the encoded data, reality is data often gets shared beyond the originally intended context Allow for exceptions for things like automated device readings, etc.
• #21: “The more re-usable a standard….. …the less usable it is” “The more specific a standard is….. …the smaller it’s scope of use”
• #22: You can constrain away stuff you don’t need You can add stuff to the basic models for your usecase “Remove and add bricks as necessary”
• #24: Luckily, our building blocks – Resources – are already less "finegrained". Slightly less flexibility – but easier to compose meaningful stuff. If you need flexibility, you can add extensions. Profiles are our building books. When just given the spec (which is still quite flexible), there's still a lot of flexibility in combining those. Profiles express what communicating partners expect to exchanging within their context and usecase.
• #25: “Drive-by” or “bottom-up” operability: “Communicate first, standardize later” But allow publication & discovery of extensions First, business partners. Then, collaborations, communities. Maybe, finally, nation-wide It’s a natural process that people will want to make it work first, then only coordinate what they really need to, and then realize they can broaden their approach to a community. “Support”, of course top-down should still be possible! Maybe even a combi in the long-term
• #26: Document every resource, every attribute Provide examples Define how to use in REST, Document and Message Manageable by a project lead in a weekend, or you’ll be ignored (in favor of local solutions)
• #42: Resource Id’s (=URLs) are infrastructural id’s, they differ from “business” identifier. Many Resources also have business identifiers, they are explicitly modeled, like Patient.identifier (even more than one identifier possible!) Business identifiers are completely separate from technical resource id’s
• #57: A profile can be published on a FHIR (based) server (it’s a Resource, after all) Or in a version-management system, or by e-mail, or… As long as people can *find* them, because publishing your profile should help others to find & adhere to it.
• #59: A server might defer validation to another server (because it doesn’t know the profile) A server may fetch the “unknown” profile and validate it itself There may be several servers sharing the work
• #62: Note: something that’s mandatory in the core definition cannot be made optional in a profile