Data model update process

[Chandan Datta]

Hi,

I am keen to know the process by which the SMART dev team is planning to handle the data model update process. 

• How are the data model updates going to impact the API itself? 
  
• Will there be any process guidance given to app devs and EMR software architects?
  

My understanding is that from the standards point of view FHIR/SMART won’t enforce any rigorous rules on the overall data model. According to the FHIR model and the SMART API, you are adopting a 80/20 approach. So a particular line of  apps(either developed by the EMR vendor or 3rd party dev) might be equivalent to using one FHIR profile. I have put down a diagram below and I would say that the process in the diagram does not look much like how a standard is maintained. Is there someone who can comment on the approaches to this issue? 

[Nikolai Schwertner]

Hi Chandan,

I am sure that Josh will pitch in with a far more detailed response. For what it's worth, I'd agree with you that SMART on FHIR could be viewed data-model wise as a particular FHIR profile (there is a lot more to it than this, but ok). Evolving any standard is an iterative process that does benefit from a robust community and feedback loop. We certainly pay attention to the feedback that we receive from folks who try to implement SMART on FHIR and constantly looking for ways to improve our documentation, standard, and reference implementation. Still, I am not sure that we are yet at this stage when the entire vendors community (in particular) is fully engaged and we can talk about a complete and closed standards development cycle. Yet, we do have partners who are investing in the concept and working on their real-world implementations, so the future looks bright at the moment.

Best,
Nikolai

--
You received this message because you are subscribed to the Google Groups "SMART App Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-app-develo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Josh Mandel]

Hi Chandan,

Thanks for writing! I think your diagram roughly captures the process -- but I sincerely hope (and expect!) we'll support tighter embedded feedback loops of "collaboration," rather than a waterfall-like process from concept -> prerelease -> release.

It's also important to separate out two fundamental levels at which changes to the specifications can occur:

1. Changes to FHIR itself. Changes to the underlying FHIR specification occur through HL7's FHIR standards development process (where the SMART team is an active participant). The scope here is quite broad (international standard for all kinds of healthcare data exchange), and decisions are far-reaching. For example, we've pushed hard for simplifications to FHIR's representation of JSON, and these changes, once incorporated in the spec, apply to all FHIR implementations.

2. Changes to SMART's "profiles" of FHIR, which could include decisions like which vocabularies to use, and which terms to use to describe particular concepts. We may wind up building some profiles ourselves, or we may be able to outsource this work to other groups currently building profiles. It's still very early days. For now, our focus has been on very high-level profiling decisions that align closely with meaningful use and certification requirements (e.g. focusing on vocabularies like RxNorm, SNOMED CT, and LOINC).

Please let me know if this helps.

Best,

  Josh