Full US Flat File of Diagnostic Centers

45 views
Skip to first unread message

Dave Vockell

unread,
Nov 12, 2012, 5:30:46 AM11/12/12
to million-hear...@googlegroups.com
Fellow HeartChallengers, 

Some concern was posted in this forum about submission risk at Apple using the incomplete and obvious test data currently available to challenge participants.

Please find attached a file in the Appendix E format with full US coverage of addresses you can include in your app for demo purposes.  These are real CVS addresses and will make your app appear complete.  This does not include the flat file data from the challenge, so if you are accessing both the LIVE service of the challenge AND accessing the flatfile, you can have both appear on your map.  I think now the flat file and live service are duplicative, so you could only use one anyway.

Enjoy.
Appendix E-Flat File - FULL US.xlsx

Jean-Luc Neptune, MD MBA - Health 2.0

unread,
Nov 12, 2012, 9:42:20 AM11/12/12
to million-hear...@googlegroups.com
Dave - This is very helpful. Thanks for sending. JL
---------------------------------------
Jean-Luc Neptune, MD MBA
Senior Vice President, Health 2.0
j...@health2con.com
www.jeanlucneptune.com
646-734-2320

Learn more about the Health 2.0 Developer Challenge:
www.health2challenge.org
> --
> You received this message because you are subscribed to the Google Groups "Million Hearts Challenge" group.
> To unsubscribe from this group, send email to million-hearts-cha...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> <Appendix E-Flat File - FULL US.xlsx>

Peter Tseng

unread,
Nov 12, 2012, 7:18:49 PM11/12/12
to million-hear...@googlegroups.com
 I think now the flat file and live service are duplicative, so you could only use one anyway.

What? So it's not necessary to implement both?

Jean-Luc Neptune, MD MBA - Health 2.0

unread,
Nov 13, 2012, 12:15:07 AM11/13/12
to million-hear...@googlegroups.com
Peter - The idea is that you should still be integrating with the Surescripts API. However, since it doesn't have much data at this point it might make sense to include Dave's more complete flat file to help provide a fuller testing experience for representatives at the App store.

Dave - Do you agree with my take?

JL

---------------------------------------
Jean-Luc Neptune, MD MBA
Senior Vice President, Health 2.0
j...@health2con.com
www.jeanlucneptune.com
646-734-2320

Learn more about the Health 2.0 Developer Challenge:
www.health2challenge.org

Dave Vockell

unread,
Nov 13, 2012, 2:30:48 AM11/13/12
to million-hear...@googlegroups.com
Evaluation Criteria #1: How well the apps follow the specific input and output requirements of the two APIs and exchange data with the data sources (Surescripts and the Community Healthcare Provider lists), as well as the Archimedes API

• The requirement will demand that an app present both the live Surescripts feed and the flatfile
• Today they are both the same, so if you demonstrated that you used both, you would have duplicate listings (unless you worked to dedupe)
• The data is all local to Minneapolis, so only a subset of our review overlords will have data on their geo-aware maps
• However, both our broader review team and whomever at Apple (if you are iOS) is reviewing the app may get a blank map and REJECT you
• This flatfile has nice national coverage and will make a populated map appear, even in Cupertino


Rock on.

> To unsubscribe from this group, send email to million-hearts-challenge+unsub...@googlegroups.com.

Bryan Weichelt

unread,
Nov 13, 2012, 9:27:29 AM11/13/12
to million-hear...@googlegroups.com

ONC Team,

I don't want to sound negative of course, but we're a bit confused as to how to proceed. Our developer spent the day configuring the new flat file yesterday, but there seems to be a change in direction since then:

 This is from yesterday's post:  I think now the flat file and live service are duplicative, so you could only use one anyway.”

 But this is from today’s post: The requirement will demand that an app present both the live Surescripts feed and the flatfile

 

This would cause a bit of re-work, but I just want to make sure we've got the final requirements before implementing. Please advise.

 

Thanks again,
Bryan

Matt Garnes

unread,
Nov 13, 2012, 9:42:00 AM11/13/12
to million-hear...@googlegroups.com
Dave,

Am I correct in saying that this flat file that you have posted here is not the official flat file from ONC, it's just test data that you have prepared for our benefit to facilitate submitting to app stores and for better testing?

Thanks for doing this, I just want to be sure of what to expect going forward if I am going to integrate this into my app. If the flat file provided in the future from ONC will be different, I will have to plan for it.

Matt

Dave Vockell

unread,
Nov 13, 2012, 11:25:38 AM11/13/12
to million-hear...@googlegroups.com
Fellow Developers, 

• The flat file I have posted is not any official file, it is to help IOS submitters avoid the risk of an EMPTY MAP during the Apple evaluation process -- if you are not submitting an iOS app, there is no need to use it.  I was hoping to share some "reduce the risk" love with fellow developers.

• The flat file is in the same format (it's in the same spreadsheet) as the ONC flat file to make it easy to use with limited additional work.

• Nothing in my posts should indicate what is required or not -- I copied/pasted that EVALUATION REQUIREMENT yesterday from the MillionHearts site.  My OBSERVATION was that currently both the live and flatfile were duplicative and you would likely have to dedupe if using both, but there is no REQUIREMENT that you do this.

Hope this clarifies. 

Dave



On Monday, November 12, 2012 2:30:46 AM UTC-8, Dave Vockell wrote:

Rick Zaccone

unread,
Nov 13, 2012, 11:36:59 AM11/13/12
to million-hear...@googlegroups.com
The problem is requiring an app store submission by the deadline. Since the Surescripts API will be broken to all but the winner, we are by definition flooding the various app stores with broken apps. There is already a problem with poor quality medical apps. We shouldn't be contributing to the problem.

http://www.washingtonpost.com/national/health-science/many-health-apps-are-based-on-flimsy-science-at-best-and-they-often-do-not-work/2012/11/12/11f2eb1e-0e37-11e2-bd1a-b868e65d57eb_story.html

We plan to submit an iOS app and Apple requires that the app description be accurate. Should we mention that people from Minneapolis will be getting bad information from our app? It seems only fair and it will probably guarantee a rejection.

Rick
Reply all
Reply to author
Forward
0 new messages