- Use existing EFI partition
- Create a new 750MB boot partition (not encrypted)
- Create a root partition.
- Setup encryption
cryptsetup formatLuks /dev/nvme0n1p6
cryptsetup open /dev/nvme0n1p6 cryptroot
Health IT Standards present an evolving landscape. Aspects of healthcare data exchange are working today, but clincians and patients face serious challenges on the ground. There are multiple perspectives about the best path forward.
Under the Meaningful Use Stage 2 incentive program, 2014-certified EHRs enable exchange of clinical data via the Consolidated CDA document format. Two key patterns are: exchange among clinicians
{ | |
"resourceType": "StructureDefinition", | |
"id": "oauth-uris", | |
"url": "http://fhir-registry.smarthealthit.org/StructureDefinition/oauth-uris", | |
"name": "OAuth Endpoint URIs", | |
"publisher": "SMART Health IT", | |
"contact": [ { | |
"telecom": [ { | |
"system": "other", | |
"value": "http://smarthealthit.org" |
for rev in `git rev-list --reverse --all`; | |
do | |
git checkout $rev; | |
COUNT=$(cat trunk/source/fhir.ini trunk/build/source/fhir.ini | awk '/^\s*$/{flag=0}flag && /=/;/\[resources\]/{flag=1}' | wc -l); | |
DATE=$(git log -1 --date=iso --format=%ai .); | |
echo "$DATE $COUNT" >> /tmp/fhir_counts; | |
echo "$DATE $COUNT"; | |
done |
Enable a common set of scopes that can be used across UMA-based authorization and "vanilla OAuth 2.0" authorization in a consistent way. In particular, support a model where apps know which permissions they'll need and can get authorized, up-front, with all of those permissions explicitly (rather than attempting a FHIR operation, engaging in an UMA flow... and then repeating this process each time the app needs to issue a new query against the patient's clinical record). Effectively it's a way to standardize the logic by which an UMA resource server knows which scopes to register when it creates
listings = []; | |
$.each($("span.txt"), function(i, l){ | |
var url = $("a", l).attr("href"); | |
var title = $("a", l).text(); | |
var posted = $("time", l).attr("datetime"); | |
var price = $("span.price", l).text(); | |
var neighborhood = $("span.pnr small", l).text(); | |
var br = $("span.housing", l).text(); | |
var fees = $("a.gc", l).text(); | |
listings.push([title, url, posted, price, neighborhood, fees].join("\t")); |
Goal of the transaction below: "Always create a new lab Observation, and also -- if needed -- create a new Patient to serve as the subject of that observation".
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...
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