Skip to main content

IRIS Chatbot Wins Award at HL7 FHIR Application Roundtable

Our development partner Chris Sprague did an amazing job with his demo of IRIS Chatbot (Facebook messenger bot that helps patients schedule doctor’s appointments and order medication refills) at HL7 FHIR Application Roundtable event.

Such a great job that the judges awarded him the 2nd best demo prize

Congratulations Chris!

Please contact us if you want to learn more about Iris and how you can use it for your patients (or embed if your patient portal)  – contact@openi.org or https://openi.org/contact/

Representing Current Medications List with FHIR

This post originally appeared on HL7 blog – reposting here with permission:

The HL7 FHIR Connectathon Medication Track

At the HL7 FHIR Connectathon 14, held January 14 – 15, 2017 in San Antonio, I participated in the medication track. See my previous post to learn more about how I ended up in the medication track.

HL7’s Fast Healthcare Interoperability Resources (FHIR®) standard has four key resources related to medication:

What’s tricky is that there is an implied workflow and hierarchy. The medication track discussion I participated in included Eric Haas, Melva Peters, Jenni Syed, Danielle Friend, and Brett Marquard. Our goal was to come to a simplified understanding.

Resources Workflow

The first three resources fit pretty nicely in a work flow:

Step 1. Someone orders medication for a patient (MedicationRequest)

Step 2. A pharmacy dispenses the medication to the patient (MedicationDispense)

Step 3. Someone (or the patient themselves) administers or takes the medication (MedicationAdministration)

So where does MedicationStatement fit into this?

It is similar to a summary/consolidation of these three resources and represents the entire list of medications ever ordered/dispensed/administered for a specific patient.

However, most electronic health records (EHRs) don’t store a patient’s medication history this way.

Typically, EHRs create an order for the medication, and as that medication gets dispensed and administered, the EHR updates the medication order to record the events and any changes. An EHR will also maintain a medication list for the patient, which is the complete list of medication a patient is currently taking.

Some of the medications in the medication list are self-reported by the patient (to record those, the EHR still creates them as an order, but designates in the order that it was self-reported by the patient).

Assuming this is similar to how your EHR records medication data, how do you share them using HL7 FHIR?

Two Common Use Cases

Let’s look at two common use cases:

First Use Case: How to share a patient’s current medication list

You can pull this data directly from your EHR’s medication list (or pull all medication orders for a patient for medications the patient is currently taking). You can then use the MedicationStatement resource to share this list.

Here are a few attributes to pay attention to:

  • Status = active
  • BasedOn – references to other FHIR resources which contributed the information in this MedicationStatement
  • DerivedFrom – references to actual EHR or pharmacy records from which this MedicationStatement is derived (for auditing purposes)
    API call will look like this:

GET MedicationStatement?patient=<patient FHIR id>&status=active

Second Use Case: How to share all medications related to a patient encounter

This will include all medication orders from your EHR related to a particular encounter. You can share these as an individual MedicationRequest resource, paying attention to the following attribute:

  • context – should refer to FHIR encounter resource representing the encounter

API call will look like this:

GET MedicationOrder?patient=<patient FHIR id>&encounter=<encounter reference>

What Happens if Medications Are Dispensed by a Pharmacy Outside the Provider Institution?

Also, if medications are dispensed by a pharmacy outside of the provider institution (for example, a UCSF specialist may prescribe a medication to a patient that is filled at Walgreens or CVS), then the EHR only knows about the MedicationRequest. The EHR does not have the information about dispense and administration.

As such, it may be desirable to get a data feed from the pharmacy, or from the healthcare payer since their claims data feed will also include any pharmacy benefits that will include the data on the medications dispensed by the pharmacy.

I’m not sure how easy it is to accomplish this, but with folks like SureScripts on their way to open up their APIs, it seems like a reasonable route to explore.

Melva Peters, one of the track leaders who hails from Canada, provided an interesting perspective on how this process works for a centralized (at least at the province-level) healthcare system. Pharmacies are required to provide a feed of their prescription-filling activities using HL7 Version 3. Any EHR in the province can subscribe to this feed so that providers may see all the prescription orders for their patients.

Conclusion: Crawl-Walk-Run

My recommendation is to follow a crawl-walk-run approach to see if you can make a patient’s current medication list visible using the MedicationStatement resource.

In the United States, the next step would be to use MedicationStatement resource that pulls data from multiple EHRs and then makes use of intelligence matching logic to create a unified MedicationStatement. This MedicationStatement would be accessible to providers across multiple organizations.

This sort of service will enable a specialist to see a patient’s up-to-date medication list from their primary care provider, as well as any other provider the patient may have visited.

HL7 FHIR Connectathon: First Time Impressions and Other Tidbits

This post originally appeared on HL7 blog – reposting here with permission:

Excitement Filled the Room

It was already 9:23 am. One could argue that on a normal Saturday morning, that’s an early start time.

But I was late. The conference room at the Hyatt Regency San Antonio on the Riverwalk was packed … and buzzing with excitement over FHIR resources, interoperability and the like:

I later learned the total number of participants at the HL7 FHIR Connectathon 14 was 200+ (a sharp increase from the 6 who attended the first Connectathon just a few years ago).

It seemed like 20+ round tables, packed close to each other, each with 6 to 10 participants, elbow to elbow. Some attendees engaged in lively discussion, some furiously wrote code, and some just stared at their screens (most displaying a FHIR resource page) brows creased in concentration.

Where Do I Start?

Why couldn’t I drag my behind out of bed a little earlier for the opening remarks so I could orient myself better?

Which table should I start from?

In this mild confusion, I walked past each table to see if I could find anyone I knew or a track I was familiar with.

What were these guys doing at a Connectathon? I had heard this wasn’t like a certification, but rather more about people testing their FHIR client or server applications against a series of test scripts.

Were there prizes?

How I Landed in the Medication Track

I saw Grahame Grieve (the “God of FHIR”) from the corner of my eye. I’d met him for the first time the week before. He gave me brief nod and carried on imparting wisdom to a seemingly appreciative colleague.

There were many tracks – from the left corner of the room to the right – Provider Directory and Scheduling, Terminology, Medication, US Core, Attachments, Care Plan, Patients (not just for Beginners), CDS Hooks (must be popular as there were 3 tables), Finance and Payers (2 tables), and so on.

Thankfully Eric Haas, who I’d met a couple of times (he lives in Napa, I’m in San Francisco), waved me over to the Medication Track. I dived right into a discussion about how to derive current medication list from the FHIR Medication resources and then …

Eight Hours Later

Fast forward 8 hours and my head was spinning from drinking from the “FHIR” hose (pardon the pun). It was amazing to get all the first-hand feedback from so many smart people, on a host of issues we were dealing with at work in designing a federated FHIR service that pulls and consolidates patient data from multiple sources.

Key Take Aways

I plan to write more about each of the tracks that I participated in, but here are a few of the quick takeaways:

  • With 200+ participants that included providers, EHR vendors, payers, developers, academics and government employees, plus the “Gods of FHIR” – the event was big enough to represent all key aspects of healthcare, but still small enough so that you could walk up to anyone and start a conversation
  • The Connectathon is not a certification. Rather, you run your client or server through a series of test scripts, work with track leaders and fellow participants to better understand the nuances of each failure case, and then make the code changes to become compliant.
  • While FHIR is a standard for data exchange, that doesn’t mean your internal healthcare data model has to be 100% based on FHIR. This seemed like a common trap people fall into as they tried to design their data repositories to be FHIR compliant. I was glad that veterans like Lloyd McKenzie, Brian Postlethwaite, and Grahame Grieve straightened me out. You should design your schema based on what suits your use case (and data sources) the best and then focus on following FHIR when you are sharing /serving that data to others.

Overall, it was very inspiring to see so many smart people working on many interesting applications, with advanced standards knowledge and all skill levels participating. As a first timer, you can’t ask for a better learning opportunity.

GreenThumb app for tracking field tasks: 3rd Place award @ #AppsForAg Hackathon

Happy to report we participated as Team GreenThumb at the 2nd AppsForAg‬ hackathon, and received the 3rd place award — maybe third time will be the charm, so look out for us at the upcoming 3rd AppsForAg hackathon in March (if we don’t release a product before then 🙂

GreenThumb-at-AppsForAg-v2

Team GreenThumb (from L: Tom Bowen, Justin Bowen, Sandeep Giri, Justin Dutra) with AppForAg event organizer Patrick Dosier on far left

greenthumb-screenshot

Screenshot: a Grower’s view of the app showing various tasks (apply fertilizer/pesticides, take soil/tissue samples, irrigation, etc) over their field map

Attach8016

Team GreenThumb hard at work at a steakhouse

Our hackathon project GreenThumb was a mobile app to assign and verify common field tasks like applying fertilizers/pesticides, soil/tissue sampling, irrigation, etc, and build a database of these events to enable historical data analytics. This significantly improves communication among crop advisors, growers, and foremen, re-inforces safety/security requirements, and improves productivity by cutting down hours for record-keeping, while enabling field-level analytics for increasing yield.

Get Rid of Duplicate Contacts in Marketo

We see this often with clients using Marketo — while it is a great marketing automation solution, chances are that you have a lot of duplicate contact records in your Marketo customer data set.

Here is what happens — you load an initial customer list into Marketo, and over time as you add new customer records to that list, Marketo may fail to check for duplicate email addresses, and instead of records getting updated or merged, you get multiple records with same email address.

And this is costly — if you are paying by the number of contacts managed within Marketo, you pay multiple times for the same person — and you also incur the infamous customer wrath of receiving multiple campaign emails from you.

How do you fix this? Hire us, of course 🙂

But seriously, we have done this enough times for customers, and now we are contemplating providing this as an automated service for Marketo customers. Our simple fix process is as follows:

  • Working with our partner company Empathy Logic, we maintain a transient customer data store for data consolidation and cleansing — which includes de-duplication and householding
  • We have connectors built to Marketo’s platform so upon your security authorization, we can pull in all your customer data from Marketo to our platform and run our de-duplication routines to flag all the duplicate records.
  • We then send the list of fixed records to Marketo platform so all the duplicates are removed from your customer data set

The time to apply this fix depends on the size of your customer data set, and speed of Marketo’s record update process – we find that it is faster to update the entire customer data set rather than making batch fixes.

We are also curious to learn if this has happened to you. and what solution approaches you have found to be effective. Would love to hear from Marketo folks as well as to what are some best practices to avoid duplicates in the first place.

NuTreeSource by Team Almond Brothers: 3rd Place award @ #AppsForAg Hackathon

“Hey guys — I’m not a techie, but I keep track of all of my farm visits and application of fertilizers and pesticides using OneNotes .. let me show you on my iPhone .. “, with that Justin Butra had us hooked on working with him at the first ever AppsForAg AgTech hackathon (in the world?) hosted at West Hills Community College in Coalinga, CA.

Justin is what they called a “grower” at this event. His life is immersed in agriculture. He advises hundreds of farm owners about managing nutrients and fertilizer, about pesticides, about irrigation. Each hackathon team needed to have a grower. We were lucky to have Justin (actually 2 Justin’s – Mr Dutra the “grower” and Mr Bowen the “hacker extraordinaire”)

IMG_0910

He also managed scope creep: “of course we could do a lot of things – but let’s focus on 1 crop (Almond), and 1 nutrient (Nitrogen, the most important, and also most difficult to manage well)”

And we gave our team a name — The Almond Brothers!

Our app NuTreeSource would do smart budgeting and tracking of how much nitrogen to apply to Almond crops to maximize yield (and reduce groundwater consumption – every bit counts in these days of drought in California)

And we would do it all within a span of 24 hours. This is what it looked like:

IMG_1321

IMG_1181

IMG_20150418_110750863

Team Almond Brothers hard at work

 

IMG_0144

Justin Dutra (Grower) and Sandeep Giri (representing Developer) posing in front of their masterpiece – whiteboard specs and mockups for NuTreeSource app

And on Sunday 11:30 – we submitted our app and our presentation. There were 6 other great teams along with us who presented. They were all great, and we learned so much from each one of them, almost in awe of how well everyone knew the space, and their innovative approaches to each problem.

We are happy to report that we received the third place award. And more importantly, we received valuable feedback on how to improve our app, which we certainly intend to.

Team Almond Brothers receiving their 3rd place award for NuTreeSource

Above all, what a great experience – to go in on a Friday evening (after 4.5 hours of driving through heavy traffic from San Francisco), and by Sunday, come up with not only application ideas vetted by a (committed) user group of growers, but also a working prototype that we can improve upon.

The smiles in this group picture tell it all. Thanks everyone!

IMG_2147

 

Meet Us at Apps for Ag Hackathon

Lately we have been fascinated with the potential of Internet of Things (IoT) in agriculture sector. So, we couldn’t really stay away from the Apps for Ag Hackathon in Coalinga, CA (apparently the Harris Ranch, place where all attendees are staying, has the best steaks in the planet, but I digress 🙂

apps-for-ag-screenshot

Anyway, the suggested projects are pretty fun – http://www.apps-for-ag.com/projects/

Come by and meet our team – Tom, Justin, and I – and if you want to join our hackathon team, even better. We will keep you posted. Cheers!