Skip to content

Instantly share code, notes, and snippets.

Avatar

Josh Mandel jmandel

View GitHub Profile
View gist:6652405
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>SMART patient bundle for transactional posting</title>
<id>urn:uuid:3380</id>
<updated>2013-09-21T07:41:22.653989</updated>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>SMART Patient-level resource</title>
<id>cid:patient-1032702</id>
<updated>2013-09-21T07:41:22.653989</updated>
View build-docs.sh
#!/bin/bash
EMAILS="addresses@go.here, separated@by.commas"
DATE=$(date +"%Y-%m-%d")
NAME="Nightly Build $DATE"
prepareToBuild (){
git reset --hard git-svn
rm fhir-error-dump.txt
rm -rf temp/*
}
@jmandel
jmandel / export.json
Last active Dec 27, 2015
BB REST API Calls for POSTMAN REST Client
View export.json
{
"id": "6ecaefca-6a4c-995c-3d7f-7b5a2b0607d4",
"name": "BB REST API",
"timestamp": 1383525089539,
"requests": [
{
"collectionId": "6ecaefca-6a4c-995c-3d7f-7b5a2b0607d4",
"id": "40947022-e6c1-d87d-38e1-b3b54bafe10a",
"name": "0. Register",
"description": "",
@jmandel
jmandel / 0-getting-started.md
Last active Nov 27, 2019
Quick Start Guide for SMART on FHIR Servers: Growth Charts
View 0-getting-started.md

Getting started implementing a SMART on FHIR server

This is a getting-started guide for SMART on FHIR server developers who want to support the SMART Growth Charts app. For background, SMART on FHRI is a plug-in app platform for health apps based on open standards.

To run SMART's open-source Growth Charts app against your own SMART on FHIR server, you'll need to:

  1. Expose clinical data using FHIR Patient and Observation resources
  2. Protect your clinical data via the SMART on FHIR Authorization protocols(based on OAuth2).

To get up and running as easily as possible, this Quick-start guide helps you through two scenarios: first, to run the app in debugging mode against an unprotected server, and second, to get the app running against an OAuth2-protected server.

@jmandel
jmandel / design.md
Last active Jan 8, 2020
Desiging a framework for triggered notifications in FHIR
View design.md

Proposal: Triggered Notifications

Use case: subscribing to specific lab observations

FHIR offers a REST API that lets clients search for resources on demand. Separately, there is a Messaging API that allows notifications to be "pushed" from one place to another. But neither API provides a clean solution to a common set of real-world "triggering" or notification-type requirements.

For example, let's say Mt. Auburn Hospital's Mother and Infant Unit wants to

@jmandel
jmandel / export_history.py
Last active Aug 29, 2015
export skype chat hsitory for FHIR Implementers
View export_history.py
import sqlite3
import json
import sys
# e.g. python export_history.py /home/jmandel/.Skype/jcmandel/main.db > export.json
c = sqlite3.connect(sys.argv[1])
c.row_factory = sqlite3.Row
cur = c.cursor()
@jmandel
jmandel / fhir-device-workflows.md
Last active Aug 29, 2015
FHIR Device Workflows
View fhir-device-workflows.md

Medical Device Workflows in FHIR

Medical device workflow are rich and complex. This design attempts to factor the domain into a minimal set of components that can be combined to produce useful systems. It's self-consciously naïve, but it should serve as a seed for discussion.

A few assumptions and a sketch

  • Any device can be online all the time, and can act as a FHIR server -- possible all on its own, or possibly with the help of a proxy/manager/facade component that "fronts for" the device. (Communication between the device and its manager occurs using any mechanism necessary; but the components below be useful for such internal communication, too.)

  • A device generates snapshot (i.e. point-in-time) reports -- which can consist of observations or alerts.

@jmandel
jmandel / 00-intro.md
Last active Aug 29, 2015
# Questions about Profiles (from Lipid Report example)
View 00-intro.md
@jmandel
jmandel / sketch.md
Last active Aug 29, 2015
SMART Support for HAPI?
View sketch.md

Here are a few components that could help. This is just a sketch -- looking to refine (or completely replace) these ideas with a more concrete proposal...

Authorization Server

A common set of components that allow end-users to authorize access to clinical data. Handles fundamental aspects of client registration, authorization flows, and token generation. Currently SMART and HSPC (and also Duke) have independently modified versions of MITREid Connect, but they all rely on different, non-compatible customizations. We'd want to build modular support for:

  • User sign-in. Should be able to tie into existing user account services -- e.g. via LDAP or any other back-end protocol. Bottom line: OpenMRS should be able to configure an instance of this server so users can sign in with their existing OpenMRS credentials (and ditto for SMART sandbox users, or HSPC sandbox users, etc).

  • App launch context communication. The SMART launch protocol allows the EHR to estab

You can’t perform that action at this time.