Category Archives: Implementation

#FHIR, CDS-Hooks, and Clinical Decision Support

This is a guest post written by Kevin Shekleton from Cerner, and first posted to the HL7 CDS email list. Reproduced here for wider availability by agreement with Kevin


TL;DR: CDS Hooks will be working with the HL7 Clinical Reasoning team to make sure our approaches are complementary, and to ensure that CDS Hooks is on a path to standardization. The CDS Hooks implementation community should expect no changes to our open, community-based development process (but should expect to see increased interest and engagement from the community).

As briefly mentioned a few days ago on an earlier thread, there is some news to share from the HL7 WGM a couple weeks ago. I didn’t share this immediately at that time because frankly, I wasn’t sure as to the details yet. Rather than posting a vague post I was waiting until we had a few more discussions before communicating this out. 🙂
During the WGM, I attended a joint meeting between the CDS, CQI, and FHIR-I working groups. During this meeting, one of the topics of discussion was a new project scope statement (PSS) to semantically align Clinical Reasoning to CDS Hooks. There was an acknowledgement by the HL7 working group of the support and interest CDS Hooks has within the EHR and CDS vendor communities, so ensuring Clinical Reasoning aligns (where/when possible) to CDS Hooks is beneficial to those planning to support both projects.
The CDS working group has been working on a model for clinical decision support within FHIR called Clinical Reasoning (formerly known as CDS on FHIR). I’ve fielded many questions from folks all asking the same thing: “What is the difference between Clinical Reasoning and CDS Hooks?”
At the end of the joint meeting, several of us stuck around afterwards to discuss the two projects in further detail. Specifically, we began to directly address that aforementioned question: “What is the difference between Clinical Reasoning and CDS Hooks?”. We all agreed that none of us have ever had a very clear response to that question, mainly because each of us have been focused on our respective projects and have not sat down recently to compare/contrast the specifics of our approaches and goals.
Bryn Rhodes (primary architect of Clinical Reasoning), Isaac Vetter (Epic), and I proceeded to work for the next 6 hours or so on educating each other on architecture specifics, projects goals, and design constraints of each project. In doing so, we came away with the following high level takeaways:
  • CDS Hooks is designed solely around the execution of external clinical decision support.
  • Clinical Reasoning was designed primarily around the definition, sharing, and execution of local clinical decision support. However, the project also defines capabilities for external decision support that are based on older specifications, resulting in the overlap with CDS Hooks.
Based upon our initial work that afternoon/night, we all agreed on several things:
  • Continuing our conversations was in the best interest of both projects.
  • Both projects should be complementary
  • The sweet spot of Clinical Reasoning is in the space of local CDS
  • The sweet spot of CDS Hooks is in the space of external CDS
To reflect this, we modified the aforementioned project scope statement to commit to continuing these discussions in 2017 with the goal of more directly aligning the projects. Specifically, we agreed to explore moving CDS Hooks as an independent entity within the HL7 CDS community to solve the problem of external CDS, leaving the current Clinical Reasoning project to focus on the problem of local CDS.
What does this mean to all of you who are implementing CDS Hooks?
Not much, actually. We’re not changing our focus or design. The simplicity and focus of CDS Hooks has been one of its best strengths which is evident in the broad support, interest, and ease of development within the community. We will not compromise that.
What does this mean for how the project is managed?
Again, not much. CDS Hooks will remain a consensus driven open source project using modern development practices and tooling and following its own independent release process. I think this has worked well for other projects like SMART. I am working on a more formal project governance (more on this later) that should allow us to continue operating as-is while simultaneously satisfying HL7’s requirements.
Additionally, all of the conversations and work we’re just now starting will be done in full view of the community. Any proposed changes to CDS Hooks will continue to be logged as Github Issues and discussed with those interested, we’ll still run Connectathon tracks to get implementer feedback, and we’ll continue to use this mailing list and Zulip for discussions.
How does this benefit CDS Hooks, Clinical Reasoning, and the community?
First, the entire CDS community will have a clear understanding of Clinical Reasoning and CDS Hooks as well as when it’s appropriate to use each approach.
Second, both projects are going to be strengthened by our continued joint work to align on shared needs, identify gaps, and work in complementary directions rather than potentially pulling in opposing directions.
Finally, having CDS Hooks published under HL7 will benefit organizations that are constrained to recommending or implementing HL7 standards.
I’m excited for the work we’re all going to do within the CDS standards communities and specifically, CDS Hooks. The community support around CDS Hooks has been outstanding and I’m looking forward to working towards a 1.0 releases of a CDS Hooks spec this year as well as our first production implementations.

Verhoeff Algorithm in Delphi

I needed an implementation of the Verhoeff check digit algorithm in Delphi, and couldn’t find one. So reproduced here for ease of use by anyone else who needs it:

const
 verhoeff_d : array[0..9,0..9] of integer = (
 (0, 1, 2, 3, 4, 5, 6, 7, 8, 9),
 (1, 2, 3, 4, 0, 6, 7, 8, 9, 5),
 (2, 3, 4, 0, 1, 7, 8, 9, 5, 6),
 (3, 4, 0, 1, 2, 8, 9, 5, 6, 7),
 (4, 0, 1, 2, 3, 9, 5, 6, 7, 8),
 (5, 9, 8, 7, 6, 0, 4, 3, 2, 1),
 (6, 5, 9, 8, 7, 1, 0, 4, 3, 2),
 (7, 6, 5, 9, 8, 2, 1, 0, 4, 3),
 (8, 7, 6, 5, 9, 3, 2, 1, 0, 4),
 (9, 8, 7, 6, 5, 4, 3, 2, 1, 0)
 );
// The permutation table
 verhoeff_p : array[0..7,0..9] of integer = (
 (0, 1, 2, 3, 4, 5, 6, 7, 8, 9),
 (1, 5, 7, 6, 2, 8, 3, 0, 9, 4),
 (5, 8, 0, 3, 7, 9, 6, 1, 4, 2),
 (8, 9, 1, 6, 0, 4, 3, 5, 2, 7),
 (9, 4, 5, 3, 1, 2, 6, 8, 7, 0),
 (4, 2, 8, 6, 5, 7, 3, 9, 0, 1),
 (2, 7, 9, 3, 8, 0, 6, 4, 1, 5),
 (7, 0, 4, 6, 9, 1, 3, 2, 5, 8)
 );
 //The inverse table
 verhoeff_inv : array [0..9] of char = ('0', '4', '3', '2', '1', '5', '6', '7', '8', '9');

//For a given number generates a Verhoeff digit
function genCheckDigit(s : String): char;
var
 i, c, len : integer;
begin
 c := 0;
 s := s + '0';
 len := length(s);

 for i := len downto 1 do
   c := verhoeff_d[c][verhoeff_p[((len-i) mod 8)][ord(s[i]) - ord('0')]];

 result := verhoeff_inv[c];
end;

////Validates that an entered number is Verhoeff compliant.
////The check digit must be the last one.
procedure validateCheckDigit(s : String);
var
 i, c, len : integer;
begin
 c := 0;
 len := length(s);

 for i := len downto 1 do
   c := verhoeff_d[c][verhoeff_p[((len-i) mod 8)][ord(s[i]) - ord('0')]];

 if c <> 0 then
 raise Exception.Create('Check digit error: "'+s+'" is not valid by Verhoeff algorithm');
end;

 

#FHIR Video Contest

We work hard to ensure that the FHIR specification is as easy to understand as possible. For example, we have several ‘getting started’ guides for different audiences. But never-the-less, getting orientated with the specification, and/or the FHIR connectathon process can still be a challenge. So today, HL7 is announcing a competition.

Contest entrants must post a video to Youtube that helps implementers ‘get started’ with the FHIR specification and/or the FHIR connectathons. Videos should be less than 5 minutes long, and be posted to Youtube by November the 1st.

Video entries will be judged by Ed Hammond (don’t know Ed? He’s “Mr HL7” is anyone is – see this award), and the winner will get free registration (or refund etc) for their next HL7 meeting.

Ed and I will be awarding some prizes for additional categories, including a ‘community preference’ award.

#FHIR and Character encoding in URLs

One issue that is causing confusion for FHIR implementers is the question of what characters need to be escaped in an http: URL. The general shape of an http: url is

http://[server name]/[path]?[name]=[value]&[name]=[value]

Examples:

  • http://acme.org/fhir/Patient/1
  • http://acme.org/fhir/Patient?gender=male&address-postalcode=12345

For a FHIR implementer, we will assume that there is no need to do escaping in the [server name] and [path] fragments (there’s possibly corner cases where you might need to, but these are either rare or non-existent in the FHIR community). On the other hand, there’s certainly specified circumstances where the parameter value is specified to contain characters that may need escaping. For example, one possible URL is:

GET fhir/ValueSet?url=http%3A%2F%2Fhl7.org%2Ffhir%2FValueSet%2Fclinical-findings

In this URL, the characters : and / have been encoded using % encoding, as specified in the http standard. (See the encoding table here, but I prefer this tool for normal use). But what characters do you have to encode like that? well, that’s where it gets a little slippery. Quoting from wikipedia:

When a character from the reserved set (a “reserved character”) has special meaning (a “reserved purpose”) in a certain context, and a URI scheme says that it is necessary to use that character for some other purpose, then the character must be percent-encoded.

The key thing here is that which characters have to be encoded depends on which characters have special meaning. In a parameter value, the character ‘&’ has special meaning – so you have to escape that. Escaping the rest is optional. So this URL is equal to the one above:

GET fhir/ValueSet?url=http://hl7.org/fhir/ValueSet/clinical-findings

as is this:

GET fhir/ValueSet?url=%68%74%74%70%3A%2F%2F%68%69%37%2E%6F%72%67%2F%66%68%69%72%2F%56%61%69%75%65S%65%74%2F%63%69%69%6E%69%63%61%69%2D%66%69%6Ed%69%6E%67%73

These are all valid, and servers should support all the possible variants. Generally, we try to keep away from specifying characters that need escaping; they just cause problems for everyone. Yes, they’re resolvable, but no, we don’t want people losing time over them, so we don’t, e.g. define parameter names with ‘=’ in them.

So, as a client, you only need to escape in a very few places. There’s one place in the FHIR spec where this escaping arises as an explicit issue, we we need escape with in the value of the parameter itself. This edge case is discussed explicitly in the spec.

Note that there’s one other case where you absolutely have to escape the parameter values: if they contain characters not in the ASCII code range of characters 33 – 127 – typically, spaces or unicode characters.

Question: Apple CareKit and #FHIR

Question:

I am very new to FHIR and now i am trying the find out equivalent resource for  Apple carekit data. I think i can use FHIR Careplan & Goal for the CareKit data. Is that right?

Answer:

I’ve not done any work with CareKit, but Apple suggested I talk to Seth Berkowitz at BIDMC, who says:

CareKit is a set of UI and database components that provide a framework to display careplans, collect patient generated data, provide insightful feedback to and from patients via their iOS phones.  By leveraging simple game mechanics and Apple’s design ethos, the UI components of CareKit help motivate patients to comply with their daily medications and activities as part of their care plan.  The assessment component streamlines the collection of subjective and objective data from patients using the phone as middleware. Objective data collection is facilitated through HealthKit, which is Apple’s centralized database on it’s phones that facilitates the sharing of objective health metrics in between apps.  The last component of carekit is a communication module that helps patients share their care plans and results with friends, family, and medical professionals

BIDMC we are integrating our CareKit app directly into our homebuilt EHR so that the app becomes a direct conduit of prescriptions and orders from doctor to patient, and patient generated data from patient to doctor.  Although our short term goal is to benefit our own population of patients, we share Apple’s long term vision of widely disseminating these engaging apps.  To that end, we are trying to leverage FHIR APIs as much as possible to serve as the connections between our EHR and the App.  The hope is that Apps like this serve as a “carrot” to promote more widespread adoption of the FHIR standard.  Our two main APIs using FHIR are a medication search bundle and CarePlan resource.  Our medication bundle leverages our institutions participation in the Argonaut projects

CareKit encompasses several functions which pose potential FHIR interfaces for data download and upload.  To date, my group has focused on leveraging FHIR for data download in order to populate the CareKit “CareCard” (a patient check list of careplan activities) and Carekit “Assessment” or subjective and objective measurements collected on the phone. An overarching question that we’ve been trying to solve is how encode UI / implementation specific data fields within the appropriate FHIR schema.  For example, a careplan activity in carekit is displayed with a title, a subtitle, and more detailed instructions.  For each careplan activity I’ve been using the following mapping

  • Title: activity.detail.code.text
  • Subtitle:  activity.detail.goal (either display or description of a contained resource)
  • Instructions: activity.detail.description

For quantitative measurements that are collected on the phone through the HealthKit database, I define an “observation” activity within the careplan.  The activity.detail.code.coding array defines a LOINC codable concept which is then mapped to Apple’s internal reference system for various physiological measurements (heart rate, blood pressure, daily sodium intake, etc)

Finally, we define certain alert conditions that may prompt a message to the patient after a measurement is obtained.  These alerts are implemented as an extension to the activity.detail.goal.  The extension includes a valueQuantity which is the threshold that triggers the alert and a referenced Flag resource which is the alert prompt to the user.

There’s much more to be done to build an end-to-end CareKit FHIR interface, but that’s what we’ve been working on so far.

Thanks to Seth and also to Pascal Pfiffner, who’s been a trail blazer with regard to FHIR use on iOS (and who maintains the FHIR Swift reference implementation).

Seth noted that with the careplan resource, it feels like they’re pushing the limits of how the careplan is being used in practice – and indeed, that’s true. There’s a lot of active projects using FHIR as the format for exchange underlying shared care/ collaborative care projects that involve the patient, and their various care teams: family, professional, social etc., and this is a new – exciting! – area where there’s not a lot of established knowledge, culture, and practice for us to fall back on. So implementers should expect more change in this area than in the well established ones (patient management, diagnostics, medication administration, billing).

Question: Binding choices

Question:

A question regarding “Standard” codes vs. Customized codes: To my understanding, if I want to exchange FHIR resource, any property in that resource can be filled by either of the following options:

  • Using the standard clinical coding system for relevant clinical properties (for example, SNOMED CT code for MedicationOrder>Medication>code
  • Using the HL7 FHIR administrative coding system for relevant administrative properties (for example, http://hl7.org/fhir/ValueSet/medication-order-status for MedicationOrder>Status)
  • Using customized, in-house, coding system, but for that I need to define it as appropriate ValueSet, bounded into appropriate Profile.

Answer:

So this answer (and the question, really) applies to any property in a resource that has a type of Coding or CodeableConcept. In principle, any property of a resource that has a type can be filled by any one of those choices – a SNOMED CT code (or RxNorm, or LOINC, or …), a FHIR defined code, or a locally defined code. However for all these properties, we ‘bind’ them to a value set, and that value set makes a rule about what kind of codes can be used.

Element <– (binding) –> ValueSet

So if the property is bound to SNOMED CT, then you have to use a code from SNOMED CT. But note that if the type is CodeableConcept, which can have more than 1 coding, then this means that one of the codings has to come from SNOMED CT – for the others, you have can use anything at all that you like.

Further, the binding itself has an important property – the ‘strength‘ of the binding. This key property tells you how to interpret the binding:

required You have to use one of the specified codes
extensible You have to use one of the specified codes, unless there isn’t an appropriate one. Then you can use whatever you like
preferred This is the sort of codes you should use – and this value set really is a good idea to use
example This is the sort of codes you should use

So the last 2 binding strengths are not, well, binding: you can ignore them as you see fit. So what you can actually use in a resource property depends on the strength of the binding, and the value set it references. But, sadly, most of the really interesting properties in most resources have a binding strength of ‘example’ – precisely because they are most interesting, we have no way to get consensus on the right coding system (let alone the right set of concepts). A great example is Condition.code:

. code 1..1 CodeableConcept Identification of the condition, problem or diagnosis
Condition/Problem/Diagnosis Codes (Example)

An example binding to a large set of SNOMED CT codes….

Finally, some notes on your choices:

  • Standard clinical coding system: we always recommend that you use one of these. But these can be hard to use. We introduced the terminology service to make this easier, and this is a concept that’s just about in the goto-market phase
  • FHIR code systems are mostly defined for the fixed properties like status where you have to use one of the fixed codes we defined, but sometimes we define a code system to be used with Coding/CodeableConcept. We generally try pretty hard to not overlap with the standard terminologies, so it’s usually a choice of one or the other
  • When you use a customised in house coding system, you don’t actually have to define it using a value set, but doing so allows you to tell everyone else in a computable fashion what you are doing, so it’s a good idea, yes.

 

 

#FHIR and the Gartner Hype Cycle

As FHIR product director, I get plenty of comments about the hype associated with FHIR. And there is plenty of hype. Here’s the Gartner hype curve:

Where are we on that curve, people want to know? Well, my answer is that as far as I can tell, the rate of increase of hype is still increasing, so it seems as though we’re still in the initial rocket phase.

What’s the hype?

For me, hype is beyond enthusiasm – it’s when people make wildly inflated claims about what is possible, (wilfully) misunderstand the limitations of the technology, and evangelise the technology for all sorts of ill judged applications (about where block chain in healthcare is right now).

So what things do I see that I think are hype? Well there are many symptoms, but one fundamental cause: there’s an apparently widely held view that “FHIR will solve interoperability”.

It’s not going to.

FHIR is 2 things: a technology, and a culture. I’m proud of both of those things. I think both of those will make a huge contribution towards solving the problems of interoperability in healthcare. But people who think that problem will be solved anytime soon don’t understand the constraints we work under.

HL7 is an IT standardisation Organization. We have severely limited ability to standardise the practice of healthcare or medicine. We just have to accept them as they are. So we can’t provide prescriptive information models. We can’t force vendors or institutions to do things the same way. We can’t force them to share particular kinds of information at particular times. All we can do is describe a common way to do it, if people want to do it.

FHIR is good for sharing information out of an EHR – but confirming to FHIR doesn’t prove anything; there’ll have to be some policy layer above that. More generally, if you have 2 teams (departments, vendors, governments, whatever) that don’t see eye to eye, forcing them to adopt FHIR as a technology isn’t going to change anything. Getting them to adopt the FHIR culture – that will. But you cannot impose that.

So what can we do about that?

What we – the FHIR team – can do is to make sure the fundamentals are in place. Good governance, solid processes, well tested specifications, an open and inclusive engagement framework. If we can get that right – and it’s a work in process – then the trough of despair won’t be as deep as it might, and we can focus on our task: getting the standards out of the way of solving problems in people’s healthcare.

Follow up: have you read my 3 laws of interoperability?

 

Question: Searching by extensions in #FHIR

Question:

My concern relates to search resources by extensions. I have read a lot about extensions and profiles, but the processing I have never seen.

If I need a new field on patient, like eye color, I’ve the option to extend the standard patient resource and add the new property. Persisting and loading via ID is quite easy. But how is the best way to realize a searching for patients with the new eye color value? Is there ever a solution?

Btw: I’m using the awesome HAPI from James Agnew.

Answer:

This is a question that comes up occasionally because the answer is buried in the spec. When you search a resource, you nominate one or more parameters to search by. In the specification, we define a basic set of search parameters, the ones we think will come up in practice. Servers can decide which of these to support, and define their own additional ones.

Note that the parameters are not direct queries into the resource – they are a name that identifies a path into the resource. The idea is that you can use some kind of map-reduce approach to generate the indexes, or map to an existing index you already have. So for patient, the search parameter “given” is actually a search onto the path Patient.name.given. The ‘path’ there is actually a fluent path expression – and finally, in the latest version of the spec, we have all the ducks in a row to make that formal and explicit.

So to search an extension, the server defines a name – say, ‘eyecolor’ in your case – and generates the index based on the expression Patient.extension(“your-extension-url”). It’s completely transparent to the client where the search parameter refers to unless the server publishes it’s search parameter definitions, and the client processes them.

Oh – but you’ll want to know how to actually do that in HAPI – you’ll have to ask on the HAPI support forum. Btw, yes, both HAPI and James are awesome 😉

Mapping between CCDA and FHIR

Across the board, many FHIR implementers have the same challenge: mapping between some other format, and a set of FHIR resources. Right now, the pressing issue is mapping between CCDA and FHIR (in both directions). At the HL7 Orlando meeting in January 2016, we held a Birds of a Feather session about mapping. At this meeting, there was general consensus that we – the FHIR community – would like to have a mapping framework that

  • allows us to exchange maps that express detailed transforms from one format to another (in terms of a previous post, executional maps)
  • means that the transforms are portable e.g. the same transform can be run on multiple different system
  • can be shared through a FHIR repository
  • allows to move data into and out of FHIR resources (or between them)

While we were at it, we noted that it would be pretty cool if the language could be used for transforms that didn’t involve FHIR either. And we decided that we’d focus on CCDA <-> FHIR as a primary use case, since that’s an operational issue for so many people. Also, we noted that there’s no existing standard that meets these requirements, or that can easily meet them. MDMI was brought forward as a candidate, but it’s not clear that MDMI solves the problems we usually encounter.

After the meeting, I sat down with Keith Duddy, one of the editors of the other leading candidate specification, which is QVT. After a long discussion about what we were trying to do, and a review of the possible candidates, Keith and I designed a mapping language for FHIR that is very much based on QVT, but leverages a number of design features and philosophies from the existing FHIR work. The work includes an abstract syntax (which is a resource, the StructureMap resource), and a concrete syntax, and a transform host API that delegates implementation specific transformation actions to the host engine. In addition, we’ve prototyped it in the context of CCDA –> FHIR Mapping. Btw, this arrangement means that Keith can take all the credit for the good parts, and I can get the blame for all the other parts.

So this mapping language is published, and open for community review. I expect that there will be robust discussion: is it rich enough? too complex? why do we need to do this? can’t we just use [insert name here]. And maybe there’s some candidate out there we haven’t found… so to help with the evaluation, we’re working on the transform from CCDA to FHIR for the Montreal connectathon.

So here’s an initial contribution to get discussion going:

Download all these, and then you can execute the validator jar with the following parameters:

 ccd.xml -transform -defn validation-min.xml.zip 
   -txserver http://fhir2.healthintersections.com.au/open 
   -folder [cda structure definitions=] -folder [map files folder] 
   -map http://hl7.org/fhir/StructureMap/cda 
   -output bundle.xml

The transform will produce bundle.xml from the CCDA input files. Alternatively, if you want the java source, see org.hl7.fhir.dstu3.utils.Transformer in the FHIR svn

Transform Pseudo Code

To help other implementations along, here’s a bunch of pseudo code for the transform engine (it’s actually pretty simple!). Note that to use this, you need to two things:

Object model – both the source object model, and a target object model express the same meta-level API, which has the following features:

  • – list children (name) returns list of Value : given a name, return all the children that have the given name
  • – make child (name) returns Value: create the appropriate object, and return it (can’t be used if the object is polymorphic)
  • – create (typename) returns Value: create an object of the specified type name (type name comes from the mapping language)
  • – set property(name, Value): set the property name to value. if name is cardinality 0..*, add to the list

And then you need a FluentPath engine that compiles and evaluates fluent path expressions:

  • – parse(string) returns expression: parse the string expression
  • – evalute(expression, Value) returns boolen: apply the expression to a value, and see whether it is true or not

Here’s the logic for the structure map transform

 transform(Value src, StructureMap map, Value tgt)
   create new variables 
   add src as new variable "src" in mode source to variables 
   add tgt as new variable "tgt" in mode target to variables 
   run transform by group (first group in map)
 
 transform by group(group, variables)
   transform for each rule in the group
 
 transform by rule(rule, variables)
   clone the variables (make us a new copy so changes don't propagate backwards)
   check there's only one source (we don't handle multiple sources yet)
   for each matching source element (see logic below - a list of variables)
     - for each target, apply the targets
     - for each nested rule, transform by rule using the variables
     - for each dependent rule, apply the dependent rule
 
 processing dependent rules
   look through the current map for a matching rule (by name)
   look through all the other known maps (in the library) for a matching group (by name)
   if match count != 0, it's an error
   check the variable cont provided matches the variable count expected by the group (and check whether they are source or target)
   make a new variables
   for each parameter, get the variable given the name, and add it to the new variables (in order)
   transform by the group using the new variables
 
 Finding Match Source Elements(source, variables)
   get the source variable with the name "source.context"
     - check it's not null (error if it is)
   if there's a condition, get the fluent path engine to check it against the source variable
     - if it fails, return an empty list
   if there's a check, get the fluent path engine to check it against the source variable
     - if it fails, blow up with some error message

   if there's a source.element
     get a list of the children with the name source.element from the source variable
   else
     turn the source variable into a list
 
   for each element in the list from the previous step, 
     clone source variables
     if there's a source.variable, add the element as to the cloned variable list using the source.element name
     add the closed variable list to the results
   return the results
 
 Apply a target(target, variables)
   get the target variable with the name "target.context"
     - check it's not null (error if it is)
   check there's an element (todo: support this)
   if there's a transform 
     value = run the tranform
     set the given name on the target variable to the value
   else
     value = make the given name on the target variable
 
 Run the transform(parameters, vars)
   depends on the transform:
   create: ask the object API to create an object of the type in parameter 1
   copy: return the value of parameter 1 (see below)
   evaluate: use the fluent path engine to execute aginst the p value of 
     parameter 1 using the string value of parameter 2 as the expression
   pointer: return the correct URL to reference the object that is the value of parameter 1 
     - which is right is a deployment decision

 The value of a parameter
   if it's an id (e.g. not a constant, just a word)
     then it's a reference to the named variable
   else 
     it's some kind of constant 

IEEE Event: Health Informatics on #FHIR

Health Informatics on FHIR: Opportunities in the New Age of Interoperability

A half day, pre-HIMSS Workshop on Saturday February 27th from 9:30 – 12:30 Westin Las Vegas Hotel, Casino & Spa

Organizers: Professors May Wang, PhD Professor (maywang@bme.gatech.edu) and Mark Braunstein, MD Professor of the Practice (mark.braunstein@cc.gatech.edu – Georgia Tech

Keynote: Charles Jaffe, MD, PhD, CEO of HL7: Toward a Global Health Interoperability Standard (30 minutes)

Panel 1: The FHIR Standard (90 minutes – Moderator: Mark Braunstein) + Panel Discussion / Q&A

  • Grahame Grieve, HL7 FHIR Project Leader: Toward Global Interoperability through the FHIR Standard
  • Josh Mandel, MD Lead Architect for the SMART on FHIR project, Harvard Boston Childrens Hospital: FHIR as a Universal App Platform
  • Charles Jaffe: The Argonaut Project

Panel 2: Healthcare in the Age of Interoperability (90 minutes – Moderator: May Wang) + Panel Discussion / Q&A

  • Robert A Greenes, MD, PhD, Professor, Biomedical Informatics, Arizona State University (co-author Aziz Boxwala, MD, PhD, Meliorix Inc, and mWorksHealth, Inc, La Jolla, CA): Enabling Patient-Centered Care by Liberating Data.
  • Jimeng Sun, PhD, Associate Professor, School of Computational Science and Engineering, Georgia Tech: FHIR-based Clinical Decision Support: An Epilepsy Case Study.
  • Paula Braun, MS Data Science Entrepreneur, CDC: FHIR and Public Health: Death Reporting Case Study
  • Gil Alterovitz, PhD, Harvard/MIT Health Sciences and Technology Division Children’s Hospital Informatics Program: SMART on FHIR Genomics

In addition, there will be up to five poster presentations available to the audience.

See IEEE page for  registration