Clinical/Healthcare Working Group

community
1

After talking with dozens of people who have expressed interest, and finally finding some folks who want to co-sponsor this project, it looks like we have the critical mass to announce a community-organized Healthcare/Clinical Working Group.

So, along with the Clinical Meteor Track thread, I thought we should open a thread for people who are interested in creating healthcare, clinical, biomedical, and bioinformatics apps using Meteor.

Feel free to use this thread for more general discussion, such as introductions, help wanted, help available, ideation, algorithm design, discussion of regulatory concerns, etc.

We’ll be announcing additional details about the Clinical/Healthcare Working Group in the upcoming weeks. Probably at least a monthly/biweekly video call. Maybe also a project homepage, working group members, training/onramping resources, etc.

18 Likes
2

Count me in Abigail =D

1 Like
3

I’m in. Looks interesting.

1 Like
4

Hi!

I’m intereseted in this kind of projects, but I don’t know very much about it. What books/resources you recommend to start?

Thanks :slight_smile:

1 Like
5

Definitely interested.

6

Hi @nullpo,
Here are a few resources that we’ve been putting together to help promote Meteor within medical, clinical, healthcare, and biomedical research environments.

We’ve recently gotten funding from a few different sources to work on this pretty-much full time; and are preparing to announce support from two open-source foundations in the healthcare industry. So, there’s going to be lots of development with these resources over the next months.
Best,
Abigail

6 Likes
7

Hi Abigail and friends,
As a physician and Meteor developer I am excited to get involved with this project. We are designing a free and open source personal health record (PHR) using Meteor and we want to package our code for easy reuse by the Meteor community.
Dave Donohue

5 Likes
8

This is interesting to me. I don’t know much about healthcare topics, but I know Meteor.

1 Like
9

This is fantastic! Thanks for spearheading this effort. Very excited to see where this goes, and I’ll do what I can.

1 Like
10

These projects do sound intriguing. I would love to help in any way I can.

Update: I realize I’m new to this topic & thread, and I don’t mean to be presumptuous, but after reading the Wikipedia article about MUMPS, and (especially) the article linked to from the Wikipedia page’s “criticism [of MUMPS]” section, I was curious to know how closely the new project is intended to follow the “design philosophy” of MUMPS.

Obviously, any Meteor app will be written in JavaScript, not anything like MUMPS syntax, but I wondered what parts of the design philosophy are viewed as worth porting to the new project(s).

I only ask this because, for anyone who hasn’t read the article the Wikipedia page links to (on The Daily WTF), the author of that article described the MUMPS programming language in a way that can only be summarized as a “monstrosity.”

1 Like
11

Hi David, Sparser, eterps

Welcome to the Healthcare Working Group! Glad to hear from the physician community, as well as newcomers to the healthcare industry! :smile:

Just as an FYI, some of the folks from the Atlanta Meetup have asked about hearing more, and we’re tentatively scheduling a public video-conference the third week of September to let people introduce themselves, have me explain some of what all is going on, let people ask questions, etc.

1 Like
12

Great question, @thebionicman.

The design philosophy of MUMPS worth keeping can be boiled down to two principles:

  • document oriented database
  • single-language full-stack framework

If you’re familiar with the current state of the EMR landscape, you’ll know that these two principles are a huge departure from the existing state of affairs. Most EMRs like Cerner, Merge, AllScripts, etc. are a tangled mess of C#, ASP, Oracle, Java, Ruby, Javascript, and various other languages running on MYSQL or Oracle. Except for VistA and Epic, which were around before SQL became industry standard and which run on MUMPS/Cache. Epic sort of represents the IBM of the electronic medical world. Whereas Cerner sort of represents the Microsoft/Oracle of the industry (and seems to be where SQL systems go to die).

So Clinical Meteor is decidedly not following Cerner architecture, and is actively positioning itself closer to an Epic/VistA architecture. Clinical Meteor sort of represents things coming back around full circle. Except updated by 20 years. :wink:

Edit: Also, document oriented database have been used in electronic medical records for 40 years. We’re looking forward to supporting them for another 40.

4 Likes
13

That’s good to hear, and reassuring. You obviously have a lot of experience in the industry. I worked as a developer for a company that was tangentially associated with clinical practice, but we did not write software for any patient-facing applications. So I know just the least slightly more than nothing about it.

From your description of the current state of affairs and the plans your group has made for progress with Meteor, it sounds like it will be an enormous improvement over the many different systems in use now.

14

Super excited about Clinical Meteor Track and Abigail’s achievements to put together this community. I created a new thread devoted to creating a Patient Health Record (PHR) or Social Health Record (SHR) using Clinical Meteor Track.

The main idea is that my team would like to coordinate efforts so we produce a successful product rather than a me-too product. And we propose that a key ingredient to success is to start marketing now. I suggest a Telescope-based community site, to involve a community of patient-early adopters, capture feedback, and market a future product.

2 Likes
15

The telescope site is a great suggestion; and may be an ideal project for somebody who has meteor experience, but not healthcare experience; and is interested in volunteering time and getting familiar with the industry.

Any thoughts on the categories we ought to have in such a site?

1 Like
16

@awatson1978 great question. I have had a few thoughts on the layout of this Telescope site. Here are some ideas, but I welcome others!

Upon your suggestion Abigail, I got a .healthcare domain name: invent.healthcare

The domain name is the tagline essentially. The idea is to build a community of people who have inspiration, ideas, frustrations, desire to create a new future of healthcare.

We have a public Trello to design invent.healthcare.
I would love it if anyone joined and added their ideas!

Good question Abigail on the categories. That is the first question. Each category is effectively a different use case for the user. I was thinking of a different Call to Action button for each category/use case. Possibly in a rotating banner.
Here are some top level categories I had in mind:

  • Apps - The community can add any health apps they have used and vote them up or down. You get an effective rating of products, as has been done successfully with ProductHunt.
  • Specs - The Specs page would say this: “Specs tell the world what features are important to you in the next gen health app. A bunch of very smart people are designing such a system right now, and they need to learn what you know! What features are key to your health?”

Beyond those 2, I am less sure of what categories to add. I can think of a bunch of other use cases but I don’t want to pollute invent.healthcare website with too many options for the user. Here are some possibilities

  • Links - Link to any health-promoting website, organization, research study.
  • Sites - similar to Links, but maybe split Research into its own category.
  • Wish - “What is your wish for the future of healthcare? What should be there that is not? Be careful you might just get what you wish for!” - overlaps with Specs and a possible alternative
  • Rules, Healthy, Diet - Our original use case for biolog.io, was to capture rules from the community. Biolog.io plans a rules engine that can flag things in a patient record. We are hoping to capture everything from guidelines from USPSTF to personal best practices. I suspect this would be premature now.

These are a bit off-topic but would be interesting, for drawing in thought leaders as they are quoted, or users who want to tell a tale.

  • Quotations - capture quotes on the future of healthcare from key books (Topol, Gawande, etc) or from whoever wants to contribute them

  • Stories - Have a healthcare tale to tell? Go for it! How could have been better?

  • Grievances - similar to stories. “WHEREAS these defects happen in our healthcare system, NOW THEREFORE we need a healthcare revolution.”

1 Like
17

Ooooh. invent.healthcare. Shiny. :smile:

So, for something like this, my initial thought is to configure Telescope as a funnel site, and use it as a design blog/discussion board. Building community can be hit-or-miss; as can be evidenced by participation rates on LinkedIn ehealthcare topics.

So, rather than measuring success by number of users or visitors; maybe measure it by the generation of design documents for a suite of next-gen healthcare apps. That way, if only a dozen people from the Clinical Meteor Working Group ever use the site, but they manage to build some awesome apps, it’s a success. Alternatively, if it gets picked up at a conference like HIMSS, SIIM, SSIH, or RSNA, it can scale up to a much larger circle of users.

So, maybe create a bit of a funnel in the categories:

  • Testimonials
  • App Review
  • Design References
  • Drafts Specs
  • Finalized Specs

Then we’ll have a bit of workflow; and can share design docs and what not.

5 Likes
18

Fantastic stuff. Interested for sure.

19

Great thoughts Abigail. I’d like to better understand each category in terms of what is the use case for that category.

Apps - People can see which health apps are recommended by the community. They can add products and also rate apps that they have used.

Specs, Draft Specs, Finalized Specs - This is hard to sell to the public. We are seeking the community to vote on features they’d like to see. Meteor achieves this for their [roadmap using their public Trello][1].
Our target audience is not that technical. So a Telescope makes better sense. How about this workflow: Users post specs on Telescope. We move high value specs to Trello, where developer community can sort out which to work on. No as for how to get users to post: I would seek focus groups from my practice to share their thoughts. I could get at least a handful of users to get things started. And as patients ourselves we certainly have ideas on specs.

Testimonials - what do you mean? Do you mean like Stories or Grievances that I described? I do think this would be a powerful use case, to capture the anecdotes of what people are experiencing and how a better health information system would have helped.

Sites, Links, Research - Similar to the apps use case, but people can add/boost/discover what are key websites, organizations, or products that are not apps. Examples: USPSTF, SnoreRx for sleep apnea
[1]: https://trello.com/b/hjBDflxp/meteor-roadmap

20

I think we’re pretty much in agreement on the use cases.

Apps - Yup.

Testimonials - Yup. Stories and Grievances. One category or two. Whichever.

Sites, Links, Research - I feel this is a bit redundant. Telescope gives sites/links a first-class treatment, and is a web based news site; so it’s kind of assumed that posts are going to have sites and links.

Specs, Draft Specs, Finalized Specs -
That’s fascinating about being able to leverage focus groups from your practice. If you think you can drive traffic that way… cool. I suppose I’m being a bit more conservative in my thoughts on how much traction the site will get, and am hedging towards the idea that maybe only developers would be using it.

But more than that, I’m interested in creating a design feedback loop. Somewhere that we can post wireframes, screenshots, demos, ad campaigns, trending articles, scholarly research, etc. And then, if somebody does a mash-up or mixes some assets together, and creates an app concept, we can bump it into a new category. And if something gets enough traction that we decide to implement something, we can then bump it to Trello to be broken down into specific parts; and we can also put the final design specs into a category where people can say ‘hey, this is all the stuff that people have decided to actually work on’.

I have a design team I’d like to be able to point at the site, and say ‘hey, sift through the Apps, Testimonials, Sites, and Links, and remix things and post them to the Draft Specs category’. And then have people comment on those specs.

And when that’s done, I have developers I’d like to point at the site, and say ‘hey, filter down to the Finalized Specs and review all the work we’ve been doing’ when I’m onramping them to projects.

1 Like