Chris Sprague did a great job on the demo at FHIR Application Roundtable at Duke University School of Medicine — remember we are looking for pilot sites to implement this
HLSI_37 – Chris Sprague: Iris Chatbot from Matt Siriouthay on Vimeo.
Chris Sprague did a great job on the demo at FHIR Application Roundtable at Duke University School of Medicine — remember we are looking for pilot sites to implement this
HLSI_37 – Chris Sprague: Iris Chatbot from Matt Siriouthay on Vimeo.
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/
This post originally appeared on HL7 blog – reposting here with permission:
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.
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?
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 MedicationStatementDerivedFrom
– references to actual EHR or pharmacy records from which this MedicationStatement is derived (for auditing purposes)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 encounterAPI call will look like this:
GET MedicationOrder?patient=<patient FHIR id>&encounter=<encounter reference>
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.
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.
This post originally appeared on HL7 blog – reposting here with permission:
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.
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?
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 …
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.
I plan to write more about each of the tracks that I participated in, but here are a few of the quick takeaways:
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.
I am going to at FHIR Connectathon and HL7 Working Group Meeting in San Antonio, January 14-17. Hope to see you there.
Sandeep
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 🙂
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.
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:
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.
“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”)
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:
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.
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!
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 🙂
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!