SMART implementation guide for EMR software providers

[Chandan Datta]

I read in one of the posts that a key goal of SMART is 'is not on cross-vendor integration but on exposing a developer-friendly API to support an ecosystem of substitutable medical applications'.

To this end, it requires adoption in the real world where EMR vendors are probably happy to go as far as HL7 2 support for the minimum compliance requirements of MU2 certification.

Is there any effort by the SMART team to provide any implementation guide to EMR vendors to make their system SMART enabled. For example, containing all the necessary info for handling different coding systems or granularity of data models.

What resources are available for EMR vendors at this stage to help correctly estimate the cost and effort for SMART enabling them? Or does the SMART team think, it's not there yet?

[Nikolai Schwertner]

Hi Chandan,

Indeed, the focus of SMART is on providing a stable platform for apps integration. Providing a messaging layer for data exchange across vendors is not currently an objective. Still, SMART can theoretically be used as a base for building a solution in that direction, although this is uncharted territory.

We do have a very high-level guide for container developers:
http://docs.smartplatforms.org/container/

Since data translation, API implementation, and other related work is very specific to each implementation, it is not an easy task to provide a cookbook for all. However, we are happy to answer questions and have a discussion with vendors interested in adoption.

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.

[Chandan Datta]

Thanks Nikolai,

I am asking the following questions from more of a solutions architect perspective.

• What I understand is that SMART is very clear on opening the health data access (through the API) up to thousands of developers motivated by the iOS/Android platform way of doing things. In this regard, currently the biggest users of healthcare software are not the end users (iOS 8 has the new HealthKit API and Apple has reported started working with healthcare providers. This is a good step, but given that Google failed to do this in the past, lets see how it turns up. Workflow integration is quite important in healthcare unlike other domains where end users can be the endpoint of a service and it's okay to have them as the information endpoint). So what is the reason for leapfrogging the EMRs and targeting directly the programmers who currently cannot do much till the EMRs interop? By this, I don't just mean messaging, but EMRs having non-proprietary interfaces. 
  
• How about EMRs just implementing the API and not opening it up to third party dev? Is the SMART team working with any real world EMR partner? Most EMR systems I think don't even have such good APIs in their own proprietary systems. 
  
• How much do the FHIR and SMART goals align and complement each other? ["Building and maintaining these data models was never our core goal" and "FHIR community has made rapid progress in developing a clean, open, developer-friendly specification for granular data access" and "Building and maintaining these data models was never our core goal"]
• Which are the top three important bottlenecks that SMART+FHIR may solve together ["FHIR standard could provide a powerful way forward for remediating a long list of informational bottlenecks in HIT", http://smartplatforms.org/2013/11/smart-fhir-and-a-plan-for-achieving-healthcare-it-interoperability/].  
• Is there any sandbox for running the fhir-starter demos without setting it up on my system?
  

My interest is beyond the current level of services at which the HIT industry is stuck with many competing standards and no platform as the one SMART envisions. I am looking at the requirements for the platform when there would be smart intelligent devices such as healthcare robots which would connect people, enable collab and empowerment in a patient-centric way. There would be new data models with data being written to by devices and programmed by end users in a workflow with integration with the healthcare system. Quite interested in the real-world application of such.

1. www.araa.asn.au/acra/acra2011/papers/pap141.pdf
   
2. ieeexplore.ieee.org/iel7/6449390/6462915/06462967.pdf
   
3. http://workshops.acin.tuwien.ac.at/HRI2014_Elderly/HRI_Presentations/Presentations/InvitedTalk/Broadbent.pdf
   

To unsubscribe from this group and stop receiving emails from it, send an email to smart-app-developers+unsub...@googlegroups.com.

[Nikolai Schwertner]

Hi Chandan,

These are all great questions, and I would love to get into a discussion about our position in the current ecosystem and our aspiration. However, I will let Josh, our lead architect, respond first.

About your question for trying the fhir-starter apps, please visit https://ci.fhir.me You can use the  demo/demo account for a test run.

Best,
Nikolai

To unsubscribe from this group and stop receiving emails from it, send an email to smart-app-develo...@googlegroups.com.

[Chandan Datta]

Thanks Nikolai,

That's very nice.

I could log into the FHIR-demo app and see the prescriptions. Are there other C-CDA data model domains that you guys are working on to include -  allergies, vital signs, lab results, smoking status for example?

--
You received this message because you are subscribed to a topic in the Google Groups "SMART App Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smart-app-developers/CnQw7zI-3-Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to smart-app-develo...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Regards,
Chandan

[Josh Mandel]

Hi Chandan,

Thanks for these questions! I'll do my best to address them inline.

• What I understand is that SMART is very clear on opening the health data access (through the API) up to thousands of developers motivated by the iOS/Android platform way of doing things. In this regard, currently the biggest users of healthcare software are not the end users (iOS 8 has the new HealthKit API and Apple has reported started working with healthcare providers. This is a good step, but given that Google failed to do this in the past, lets see how it turns up. Workflow integration is quite important in healthcare unlike other domains where end users can be the endpoint of a service and it's okay to have them as the information endpoint). So what is the reason for leapfrogging the EMRs and targeting directly the programmers who currently cannot do much till the EMRs interop? By this, I don't just mean messaging, but EMRs having non-proprietary interfaces. 
  

We don't necessarily look at the SMART API as "leapfrogging" electronic health record vendors or products. To the contrary, we believe that one of the best ways forward is to work with EHR vendors to support a common, open API that runs on top of their existing products. There's a large vendor community out there today: on the order of a thousand certified EHR products in the US. We don't expect (or require!) everyone to jump on board. Rather, we're passionate about working with the set of vendors who really believe in this value proposition. But this is a classic "chicken and egg" problem, so we're doing our best to fuel adoption from all sides: by promoting the development of innovative, clinically relevant apps; by working with vendors to support implementations; by building some integrations ourselves. (We are also independently exploring what we sometimes call "sidecar" strategies that enable health apps without depending directly on the EHR -- for example by building on top of clinical data warehousing systems like i2b2.)

 

• How about EMRs just implementing the API and not opening it up to third party dev? Is the SMART team working with any real world EMR partner? Most EMR systems I think don't even have such good APIs in their own proprietary systems. 
  

I think there's very strong value in open APIs that are consistently implemented across vendor systems. But this doesn't necessarily imply that access is free and open to all comers; I expect that some vendors will want to lock down access, especially as they first get comfortable with the technology stack. That's okay: at least it moves the discussion forward to "how can I get access to this well-specified, well-implemented API endpoint?" rather than "what sort of proprietary, minimally-documented APIs are available in your environment?"

• How much do the FHIR and SMART goals align and complement each other? ["Building and maintaining these data models was never our core goal" and "FHIR community has made rapid progress in developing a clean, open, developer-friendly specification for granular data access" and "Building and maintaining these data models was never our core goal"]

Our current engineering work is focused on SMART on FHIR. We're continuing to support the RDF-based "SMART Classic" platform as we put the basic FHIR-based building blocks in place. But overall, there's very strong value in having a consistent, standards-based set of data models behind an app platform -- assuming those data models are useful and usable (and I believe FHIR meets the bill here). 

Effectively there are three ingredients we're adding on to FHIR to make this work:

1. "Profiles" that tighten down optionality in the FHIR data models (including fixing vocabularies to a small, well-known set of  standards, rather than allowing a proliferation of local codes).

2. Consistent Authorization mechanisms to delegate access to apps. (FHIR mainly leaves security out of scope, focusing on the clinical data models and RESTful API, and defining these components in a way that's broadly compatible with a variety of implementation environments.)

3. Consistent ways to embed an app's UI inside of an EHR system, including context-passing from EHR to the app.

With these ingredients, SMART on FHIR is in a very strong position to provide an open standards-based app platform.

 

• Which are the top three important bottlenecks that SMART+FHIR may solve together ["FHIR standard could provide a powerful way forward for remediating a long list of informational bottlenecks in HIT", http://smartplatforms.org/2013/11/smart-fhir-and-a-plan-for-achieving-healthcare-it-interoperability/].  

The bottlenecks are familiar and pervasive: lack of automated access to well-structured clinical data at nearly any institution you care to name. A dearth of openly-documented APIs for integrating third-party functionality. And an intense heterogeneity in data that you might manage to wrangle from these systems.

 

• Is there any sandbox for running the fhir-starter demos without setting it up on my system?

Nikolai has already shared a link here (thanks!). I should note that development is early and very much still in flux, but our documentation is coming along very nicely: http://smart-on-fhir.github.io/

My interest is beyond the current level of services at which the HIT industry is stuck with many competing standards and no platform as the one SMART envisions. I am looking at the requirements for the platform when there would be smart intelligent devices such as healthcare robots which would connect people, enable collab and empowerment in a patient-centric way. There would be new data models with data being written to by devices and programmed by end users in a workflow with integration with the healthcare system. Quite interested in the real-world application of such.

This is very much the future that we're all looking forward to -- and striving to realize!

One more comment, regarding your question about the fhir-starter kit:

I could log into the FHIR-demo app and see the prescriptions. Are there other C-CDA data model domains that you guys are working on to include -  allergies, vital signs, lab results, smoking status for example?

So, the FHIR demo apps aren't using C-CDA (they're using FHIR). The data we're exposing today are: demographics, medication prescriptions, medication fulfillments, vital signs, lab results, and problem lists. FHIR has models that span much more of the clinical domain than just these -- but getting access to freely redistribute, realistic sample data is a real challenge. Which is why we still present a relatively limited set of sample data in our sandbox. 

Best,

  Josh

[Chandan Datta]

Thanks Josh,

Really helpful to get a conceptual pragmatic understanding of this from your answers. Appreciate your time for that. Apologies if I was a bit critical with my questions.

Seems like the SMART-FHIR direction is towards a sidecar with real EMRs, which is where I landed here after reading the complete note: https://www.gartner.com/doc/2688022/healthcare-delivery-organizations-avoid-pitfalls

 I was incorrect about the C-CDA here. It's FHIR.

I haven't seen any other demo of FHIR with a EMR backend that works.

--
You received this message because you are subscribed to a topic in the Google Groups "SMART App Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smart-app-developers/CnQw7zI-3-Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to smart-app-develo...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Regards,
Chandan

[Chandan Datta]

There seems to be telepresence robots at the Children's hospital.
http://www.vgocom.com/telemedicine-market-expected-double-five-years

Are you guys involved/aware of it?

On Wed, Jun 11, 2014 at 4:21 PM, Josh Mandel <jma...@gmail.com> wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "SMART App Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smart-app-developers/CnQw7zI-3-Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to smart-app-develo...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Regards,
Chandan

[Josh Mandel]

Hi Chandan,

Thanks for the link -- the SMART team isn't involved.

Best,

  Josh

--

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.