Difference between revisions of "FHIR marketing"

From HL7Wiki
Jump to navigation Jump to search
m
Line 1: Line 1:
 
{{FHIR Discussion Page}}
 
{{FHIR Discussion Page}}
 
[[Category:Active FHIR Discussion]]
 
[[Category:Active FHIR Discussion]]
 
From a marketing perspective, there are open issues related to branding/naming and positioning.
 
  
 
This page will be subject to discussion by the HL7 Marketing council as well.
 
This page will be subject to discussion by the HL7 Marketing council as well.
Line 9: Line 7:
 
Positioning: how is this product related to other (HL7) standards? How do we explain its relationship to these other standards?
 
Positioning: how is this product related to other (HL7) standards? How do we explain its relationship to these other standards?
  
===Positioning of FHIR as a product/version of v3/implementation guide/ITS===
+
PR points of FHIR:
*The main positioning question is, even when not in name, is this "v4" (a big leap forward, largely uncompatible with v3-as-in-HDF), or is it v3.1 (a way of implementing v3). We're talking perceptions here. CDA is percieved to be something other than v3, which is why it has its own brand name & recognition.
+
*Ease of implementation
 
+
*Leverages established IT standards
Summary: position as a new product, not as a kind of "v3.5". Association with "v3" product shopuld be avoided.
+
*Leverages Web 2.0+ standards
*Jean: we want to be able to tell implementers - look! there is a path from the existing v3 specs to FHIR
+
*Optimized for Cloud-based applications
*Lloyd: Those who are already on the v3 bandwagon will understand the similarity of FHIR and we'll also provide a migration path for them, so marketing to them is less important.  (And it's not like there are huge numbers of them anyhow.)
+
*Interoperable support for document, message, REST and SOA architectures
  
===Positioning of FHIR versus CDA===
+
When asked, not part of the 'push' PR points:
*FHIR and CDA compete in the same space, so the question of positioning is important.
+
*Q: "Is FHIR a replacement for X?" (with X being v2, v3 or CDA)
*Ewout: Occurred to me that though FHIR makes transactions way less prominent than CRUD, I heard noone ask: 'where did our large-granularity interactions go'?  Generally it looks like a bunch of assembled resources are pretty much everybody mainly needs. Might I be so bold to generalize that a CDA document is a Document FHIR with a complex serialization scheme ;-) But we don't require narrative.... so are HL7 FHIR and HL7 CDA competing for the same space?
+
*A: "HL7 International strives to meet industry needs as best as possible. FHIR can be implemented in a way that meets the needs covered by X, but FHIR is in its early stages so implementations at this stage would be considered "bleeding edge". HL7's 25 years experience has shown one thing: there continue to be markets for all HL7's standards and HL7 will continue to support all its standards, including X, as the market demands"
*Rene: ultimately: yes. CDA R3 could be defined to be FHIR-based.
 
* GG: I heard lots of people asking where large granularity interactions went. Indeed, this was the single biggest question
 
*Rene: let's use that signal to priotitize the discussion how we should position FHIR vs CDA.
 
  
 
===Impact on existing product positioning===
 
===Impact on existing product positioning===

Revision as of 09:10, 25 August 2012

This page will be subject to discussion by the HL7 Marketing council as well.

Positioning

Positioning: how is this product related to other (HL7) standards? How do we explain its relationship to these other standards?

PR points of FHIR:

  • Ease of implementation
  • Leverages established IT standards
  • Leverages Web 2.0+ standards
  • Optimized for Cloud-based applications
  • Interoperable support for document, message, REST and SOA architectures

When asked, not part of the 'push' PR points:

  • Q: "Is FHIR a replacement for X?" (with X being v2, v3 or CDA)
  • A: "HL7 International strives to meet industry needs as best as possible. FHIR can be implemented in a way that meets the needs covered by X, but FHIR is in its early stages so implementations at this stage would be considered "bleeding edge". HL7's 25 years experience has shown one thing: there continue to be markets for all HL7's standards and HL7 will continue to support all its standards, including X, as the market demands"

Impact on existing product positioning

  • Product: RIM
    • The mere existence of FHIR means that we need to better market the RIM as a product independent of v3-as-in-HDF, i.e. RIM is not just part of v3, it is also part of other things.
    • LM: The theory had been to market v3 as an encompassing brand of which CDA, CCOW and other things. However, that hasn't really succeeded. If we're going to have multiple products (CDA, v3, RFH, etc.) that are all based on the 'v3 infrastructure', we should probably have a way of expressing that.
      • Rene: we'd only need to express that if it is seen as important for marketing purposes. Lots of car manifacturers build diffrerent car models on top of one and the same base platform - it's in their interest that the customer is NOT aware of this, which increases the perception of "newness"/"innovation" of a car model. I'm not saying this applies in this situation, but we could end up positioning things as siblings in a product catalog (marketing view) that are seen as children by a standards creator. v3 has effectively come to mean "HDF, RIM based static model refinement". RIM is a separate product, datatypes are a separate product, CDA is a seperate product, FHIR is a seperate product. If we decide to depart from "HDF, RIM based static model refinement" (aka v3) this will only effect the v3-product, and not the other products.
  • Product: Datatypes
    • FHIR introduces a new release of the datatypes specification.
      • Jean: Is this true? I wasn't sure if this is just a new implementation of the Abstract Datatypes or if this was an amalgam of existing XML types with extras from 20190.
      • LM: There are new types and changes to existing types. While there's a relationship to Abstract/ISO, it's definitely not the same.