Monthly Archives: September 2014

New #FHIR Open License

Today, HL7 released an updated version of the FHIR™ Draft Standard, which is now covered under a Creative Commons License: No Rights Reserved. This marks the formal adoption of a recognized open license for the FHIR specification, and one that is truly open: this is an unencumbered license. Under the terms of the Creative Commons license, HL7:

… has dedicated the work to the public domain by waiving all of it’s rights to the work worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.

This is a truly open license – even more open than most open source projects, which usually require some form of attribution. However since FHIR is a standard, and many implementations will be required to implement it, it would be inappropriate to require acknowledgement of the specification. Note, though, that the reference implementations may require attribution – and most of them use a mix of BSD or Apache licenses that do.

It should be clear, though, that HL7 has not chosen the public domain license because we don’t care about FHIR – on the contrary, HL7 cares greatly about FHIR and is investing heavily in it. HL7 wants all health care systems, whether commercial or open source, to use the FHIR specification – hence the unencumbered license terms. Because HL7 cares about the specification, it means that HL7 needs to protect the Trademark carefully, since control of the FHIR specification is how HL7 derives value from it’s investment. So the specification itself makes this clear:

HL7 protects the “FHIR” trademark carefully. This means that:

  • You cannot publish an altered version of the FHIR specification unless it clearly identifies that it is a derivative specification, not FHIR itself
  • Derivative Specifications cannot redefine what conformance to FHIR means
  • The letter sequence “FHIR” can only appear as part of a product name with specific written agreement from HL7
  • You can only use the FHIR logo as part of a commercial product with specific written agreement from HL7
  • When used in other contexts, the word “FHIR” and the “FHIR” logo should bear the ™ symbol

The point isn’t to restrict the use of the name FHIR, but to prevent it from falling into ‘common use‘. Where FHIR is used as part of an existing product name – whether a commercial product, or an open source server or library, please contact to ask for this permission (I need to do this myself). Note: As a point of reference, you can compare these rules to the Mozilla Foundation’s equivalent policy.


In the past, FHIR was published under a different license, adapted from OMG (thanks for Richard Soley for allowing this), but using a custom license increased implementation costs, and caused perceptions that the FHIR license wasn’t a proper open license. This new license doesn’t change the effective license terms that apply to FHIR at all – it’s just an expression of the same intent in a form that is more aligned with the open software and standards communities. Changing the license was a process that involved agreement from a very large number of people with HL7, and the fact that this has happened shows the importance that HL7 places in FHIR’s openness. I’d like also to thank two people outside HL7 who particularly contributed to the process – Paul Biondich (from Regenstrief / OpenMRS) and Larry Rosen.

Specification Technical Correction

The update to the license was accompanied by a technical correction to the specification itself. Quoting from the version history entry:

Fix major bug in reading/writing JSON instances: the json equivalent for xml:id is specified as “id” but the java reference implementation had been using “_id”. This is a breaking changed for users of the JSON representation using the Java reference implementation. Note also that this means that all the example JSON instances in the specification were wrong; these have also been fixed in this update

Because of this, the reference implementations and the test servers accept either “id” or “_id”, but “id” is correct.

So the spec used to have, for JSON examples such as this one:

  "contained": [
      "resourceType": "Observation",
      "_id": "obx1-4",

and now it has

  "contained": [
      "resourceType": "Observation",
      "id": "obx1-4",

This only affected contained resources. Thanks for Doug Martin from Regenstrief for pointing this error out.

Reference Implementations

This updated version of the FHIR specification includes updated reference implementations, and an updated maven package has also been posted.

#FHIR DSTU2: Changing the Composition Resource

While in Chicago, one of the decisions that we made was to refactor the Composition resource. Here’s the design in DSTU #1:


The design can be summarised in prose:

  • A section has a title and a code that describe it, and it may have a section if the subject is different to the overall composition (documents that span multiple subjects are not that unusual)
  • A section can contain other sections, or a resource that contains the content for the section
  • The resource is allowed to be any kind of resource, but the most common kind is a List resource.

Observationally, almost all CDA sections are a list – medications, problems, diagnostic reports. There’s a few exceptions: a synopsis section, a care plan. But these are the minority.

There’s a major problem with this design, which revolves around the narrative/text dynamic in a document – what happens if there’s no entries, and only some narrative? Do you have to use a different resource type (other?) if you don’t have structured content (and actually, the way resources are defined pushes you in this direction, because many of them have required data elements, and you can’t use them if all you have is text (that’s a different issue for potential resolution elsewhere).

After a fairly long discussion about this problem, and consideration of a number of alternatives, the structured document working group decided to try this design:composition_dstu_2

This design can be summarised in prose:

  • A section has a title, a code, and an identifier that describe it. Note: the identifier should only be populated if it is persistent across different compositions (unlike CDA, where slippery ids are a source of confusion)
  • A section can have narrative, and an empty reason, or sub-sections or entries (can’t have sub sections and entries, and must have a narrative unless it has sub-sections
  • The narrative is the ‘attested content’ for the section (see CDA definition)
  • Entries provide supporting data for the section narrative
  • If there are no entries and no sub-sections, there can be an empty reason. This is for things like “No medications prescribed” or “None known”
  • A code can be provided indicating what order the entries are in (the narrative order should match the order of the entries, but what is that order – chronological?)

Essentially, the relevant capabilities of the list resource have been conflated into the section.

This has the following advantages:

  • All the attested narrative is inside a single resource
  • The structure much more closely matches CDA (this will help with CCDA/FHIR implementation efforts that are ramping up)
  • There is no ambiguity about what kind of resource to use
  • There’s no confusion about the list snapshot mode – some of the list capabilities don’t make sense in a composition

There’s some potential downsides to this structure – particularly around conformance, and these are the subject of active development and testing, so implementers shouldn’t assume that this is the last word on the matter.

#FHIR Report from the Chicago meeting

Here’s a FHIR progress report from the HL7 working meeting in Chicago held the week before last.

General Progress

Overall, the hype about FHIR is astonishing, and I don’t see any evidence that it’s starting to slow. While we were in Chicago, Wes Rischel made some interesting comments about where FHIR is (though following his logic, our current task is to bring on the trough of disillusionment as soon as possible) . The FHIR project team is aware that there is a duality here: expectations and excitement about FHIR are high, but what we have published is still an early beta, and FHIR is not yet ready to meet the expectations that people have about it. We intend and expect to get there, but it is important that stakeholders and implementers understand that there’s still a lot of work to be done.


At the Chicago meeting, we held two connectathons: our normal implementer connectathon, and a clinical connectathon.

The normal connectathon was a largest yet (close to capacity). Each connectathon, we grow in 3 respects: the number of attendees, the scope of the specification that we test, and the sophistication of the outcomes. What really pleases me is that it’s not just old hands that produce sophisticated outcomes, but first time attendees who are able to use FHIR to extend their existing applications and platforms to create interesting new solutions. Sadly, the things that are seen and/or shown at the connectathon are not packaged in a way suitable for publication – maybe this is something we can change next time? (There’s an opportunity for a volunteer there). This connectathon included a focus on Smart on FHIR, and this created something new for us: a strong focus on servers rather than clients.

The clinical connectathon was something new. We held the clinical connectathon because we recognise that the connectathon process is fundamental to the strength of the specification – we’ve tested the technical interoperability aspects repeatedly, and improved the specification in response to what we’ve learnt. We know that the strength of FHIR isn’t because we’re clever, but because we keep testing it. However our existing connectathons are limited in that they require users with development tools – they are focused on system implementers. Users with clinical knowledge are generally excluded from participating, and we’ve not tested the suitability of FHIR for clinical interoperability. In fact, this is the gap between hype and reality that is our most pressing concern. The clinical connectathon intended to begin addressing this gap.

The clinical connectathon focused on clinical exchange – that is, clinical users connecting with each other. For this, the patient care group co-chairs prepared a set of clinical scenarios, and the FHIR project team provided a single tool that all the users would use to enter a set of data for an exchange associated with the scenario. Users would then review what they received and compare it to the scenario. Because all the users have the same tool, and the tool is focused on the specification, rather than being a normal EHR, this is about testing the specification, not some other software.

Technical note, for those interested: the tool has 2 parts, client and server. The client was written primarily by Peter Bernhardt (a huge effort, thanks) with assistance from David Hay and Viet Nguyen, and the server is For the data entry, the server converts a profile to a questionnaire, the client presents the questionnaire, creates a set of answers, and then the server converts these answers into a resource that conforms to the profile.

On the day, the clinical connectathon reminded me of the first normal connectathon we had – the potential of both FHIR and the connectathon was evident, but we didn’t get that much achieved on the day. For the clinical connectathon, we identified plenty of opportunities to improve the tool, and identified a number of questions about how the common clinical scenarios should be represented in the resources. Most importantly, for me, my success criteria for the first connectathon were met: all participants agreed that it was a worthwhile exercise, and that it’s worth continuing, and that we now have a better way to drive clinical engagement with the specification.

Status of the FHIR community

Up to now, FHIR has primarily been a standards project: a group of people with a core task of producing a standard. In order to do produce a good standard, we’ve had a strong implementation focus. That is, we worked with implementers in order to produce a better standard. But we recognize that the focus now needs to change: we produce a standard in order to enable implementations to solve important problems. The FHIR project and management teams will place increasing focus on implementation and engagement with a wider community. One tangible result of this is that we’ll create a home for the FHIR community at, which presently simply redirects to the specification. I’ll post more about this later.

Implementation Guides

This meeting also represented the first ballot of a FHIR implementation guide – a draft for comment ballot of the U.S. Realm ONC Structured Data Capture project). It received over 200 comments from 20 voters.  We still have work to go on how implementation guides will be produced, but this is a start.  In the December-January ballot cycle, the entire IG will go back to ballot, this time with the entire FHIR specification as part of a second “draft for comment” in preparation for the DSTU ballot cycle in May.

Generally, the infrastructure to produce implementation guides will be a major focus for the core team in the next couple of months – we’re now working a number of implementation guides in addition to this one.

Administrative Details

  • We published an initial set of “FHIR principles” for consideration. These are important because they define the scope of what FHIR is and is not, and the principles that we keep in mind when evaluating change proposals
  • We initiated a process to QA review all the codes that are defined as part of FHIR, and to see whether we can get them from somewhere else. Also, we will be working on a social-media driven process for design review of FHIR value sets, since these codes often have a different life cycle than simple ballot (e.g. once published, they can be pre-adopted by users without going through ballot first)
  • We are getting closer to publishing a registry for FHIR profiles, value sets, etc. An RFP calling for the provision of the services to support this will be released soon (if you are interested, subscribe to the FHIR email list)
  • Exactly what the letters “FHIR” stand for is a little difficult to pin down. The specification itself offers 2 different meanings, and educational material offers more. The correct name is “Fast Healthcare Interoperability Resources”, and the specification will be updated soon


We have now started on the work of preparing the next version of FHIR in earnest. It’s going to be big task; as of today there are 316 open tasks relating to the next specification. While in Chicago, we made a number of decisions that are breaking changes for the next version of the FHIR specification:

  • We will change two data type names:  “Schedule” to “Timing” (We want to use Schedule as the name a resource), and “Contact” to “ContactPoint” (to resolve implementer confusion about double use of the name “Contact”
  • We will change the way that extensions are represented in JSON (I’ll post about this more later)
  • We will change the way a Composition is stitched with it’s content (next blog post)
  • We will change the way that version specific updates are performed to align with other web specifications
  • We will add multi-lingual support to the value set resource (and will extend the specification infrastructure to make use of it)

Note there are other changes already made, see

In addition, we’ll be working on adding a bunch of new resources:

  • Nutrition Orders
  • Financial transactions
  • Information sharing consent
  • Device management

Finally, we decided that future connectathons at HL7 working meetings will be based on the future DSTU version

Other Details

  • We were pleased to welcome the OpenMRS team to the connectathon for the first time. We expect to have an ongoing and increasingly fruitful collaboration between the FHIR and OpenMRS communities. One aspect of this that we will be looking at is what we can do to make FHIR more suitable for use in communities other than the developed world – this has both technical and requirements based implications.
  • We are hoping to add sections to the specification dealing with the complicated issues around handling identification and record keeping associated with the birth process, and how to code genetic mutations for oncology.




HL7 Australia #FHIR Forum and Connectathon

On Thursday & Friday 6-7 November 2014 Hl7 Australia is holding a FHIR Forum and Connectathon in Melbourne.

Day 1 is focused on education:

Keynote: FHIR in context … a step forward for patients Andrew Yap, Alfred Hospital Melbourne
FHIR – A US perspective David McCallie, CMIO, Cerner
Implementing FHIR for Australian GP Systems Brett Esler, Oridashi
FHIR / openEHR collaboration Heather Leslie, Ocean
FHIR & the Telstra eHAAS design Terry Roach, Capsicum / Telstra
Introduction to SMART on FHIR Josh Mandel, Smart / Boston Childrens
Using Terminologies with FHIR Michael Lawley, CSIRO
Using FHIR in new and unexpected ways – actually including the Patient in the system Brian Postlethwaite, Telstra (DCA)
Clinical records using FHIR David Hay, Orion Healthcare
Panel: What are the prospects for FHIR Adoption in Australia?

  • Grahame Grieve, Health Intersections (FHIR Project)
  • Richard Dixon Hughes, DH4 (Standards)
  • Tim Blake, Semantic Consulting / DOH (Government)
  • Peter Young, Telstra  – DCA (Industry)
  • Malcom Pradhan – Alcidion (Clinical)


Im really pleased about this program: it’s a great line up of speakers from Australia and New Zealand talking about what they’re actually doing with FHIR. Also, I’m really pleased to welcome David McCallie, the CMIO for Cerner, who’ll be joining us from USA by video to discuss Cerner’s plans for FHIR and discuss the broader prospects for the adoption of FHIR in the USA. Finally, we’re really lucky and extremely pleased to have Josh Mandel from Boston Children’s Hospital Informatics Program present. Josh will be talking about SMART on FHIR, and describing how that works as an EHR extensibility framework.

On Day 2, we’ll be holding a connectathon. We’ll have 3 streams of activity:

  • Basic Patient Stream – this is suitable for any developer with no prior experience of FHIR necessary – all you need is a working development environment of your choice
  • Smart on FHIR – this is for EHR vendors who want to experiment with using Smart n FHIR as a plug-in framework for their system, or for anyone who’s interested in writing an EHR plug-in – as many clinical departments will be
  • Clinical Connectathon – this is for non-developers who still want hands on experience with FHIR – use the clinical connectathon tools to learn how real world clinical cases are represented in FHIR resources

I hope to see all of you there. To register, go to, or you can see the formal program announcement.

p.s. it doesn’t say so on the program, but there’ll be a conference dinner on the Thursday night.

Question: FHIR release schedule


I’m using the Java version of FHIR release 0.81. A bug fix that I needed required a later version of the code. I downloaded the code (rev. 2833) from SVN and, following the directions on the FHIR build page, had no trouble recompiling all of FHIR. Since rebuilding and replacing FHIR in our application is time consuming, I have some questions concerning release management:

  1. Is there a published release plan and schedule for FHIR?
  2. Is there a mechanism for patching or updating FHIR code between releases?

Note: this question was originally asked on StackOverflow where it was (a little unfairly) ruled out of scope.


The FHIR project is a combination of a specification, and a set of source that supports it. The project life cycle is driven by the considerations that flow from this.

The trunk version of FHIR is the current development version of FHIR, what the team works on from day to day. As a matter of ongoing work, it is not stable, and there is no guarantee that it is coherent and/or correct. The trunk version of FHIR is published here:

Periodically, the core editorial team that works on the specification and the code will determine that there have been enough changes and there is enough stability to publish a development release. These are published here: We typically keep upcoming connectathons that intend to use a more recent version than the formal DSTU in mind when we do this. This effectively corresponds to a beta release. Change notes and release notes are prepared when this is done.

Finally, HL7 ballots FHIR through the formal standards processes. The ballot process is based on the trunk version, and is the principle driver of the project development work. Once the ballot is passed and finalised, then a branch will be created for that formal publication – so far, there has only been one, the first DSTU (draft standard for trial use), published Feb 3 2014. This is published here:

A little further information can be found in our version numbering/change tracking policy.

Future plans:

  • We have no formal plans around when new development releases are made – this will happen periodically
  • We plan to close the next ballot cycle around May/June next year (e.g. 2015), and publish the 2nd DSTU then
  • Then we will start working on the full normative release, perhaps end of 2016. note that there can be no formal timeline for this, because it depends on the ballot process

A note about DSTU: from a software perspective, the 1st DSTU was a full release of working software. From a standards perspective, this is a beta release. Once a full normative standard is released, different change control policies kick in.

With regard to patching the FHIR code between releases, the reference implementations are actively maintained. The major ones (Java, C#, and pascal) are maintained in (or for) both the trunk and the DSTU branch (tagged DSTU1). We do periodic releases to them as major bugs are identified and fixed.

The DSTU branch has a history.

Specifically, with regard to the Java Reference Implementation, as of 12-Sept 2014:

  • We will maintain Maven releases for both the DSTU and development releases. The dev/trunk is not published to Maven
  • The original DSTU release was numbered 0.80. After a large argument about version numbering, we changed that version number to 0.0.81, and both of these are published on Maven. 0.0.81 supercedes 0.81
  • The specification will change to reference the correct Maven package directly next time it is published
  • A new release for the DSTU version is required now., because of a significant issue in the json represented, but there is considerable due process to releases in the DSTU branch, and the process isn’t quite finished yet.
  • I will be updating the development version immediately after the Sept 2014 connectathon, including releasing a new dev version

20 Questions #6: Optionality vs Extensiblity

In the 6th question of the 20 Questions seriesGreg Meyer, asks:

Optionality vs Extensibility: What effect is the large selection of standards and technology in the health IT domain having on interoperability? Do we need to eliminate optionality and focus more on extensibility?

There’s a bit more context with the question:

In my view, optionality is the death sentence of interoperability. That statement deserves a bit a context starting with the definition of optionality. Simply stated, optionality is the ability to choose one or more entities with complete disregard to supporting alternate entities. Applying that to interoperability, it means you can choose a single option (or multiple) from an enumerated set of options to perform a task without the requirement of supporting the rest of the options in that set. The result is a multitude of systems supporting different option sets where there may be no intersection of compatible options. The end game: no universal interoperability.

The real problem here is lack of alignment of use cases. Why aren’t the use cases aligned? Maybe the options truly are irrelevant – for instance, there’s no point expecting a physiotherapist package to supporting prescribing medications, for instance. On the other hand, two applications that both are a core EHR, why don’t their use cases match? There’s a number of reasons for that, including that there’s no consensus in medicine as to what the core use cases are. Also application history/legacy, different marketing/product strategies, and the personal choices of the key clinical and technical people as the application was taking shape.

If 2 applications don’t share the same set of use cases, then there won’t be any interoperability between them, or it will be fitful – like pasting content between word and a browser and vice versa – it kind of sorta works. Most of the time, but you’ll often have to manually fix it for things that didn’t work how you wanted it to. In these cases, the choice of optionality vs extensibility is moving deck chairs around on the titanic, and there’s not much you can do. Following this thought experiment, it means that resolving optionality is the same as resolving the use cases, and the problem is that IT people can’t do it, and clinical people don’t yet see the need to do it.

Given that we can’t resolve the problem, which is the best way to do it? In HL7, we generally call this the minimal vs maximal approach. We have a set of use cases that create overlapping wire format requirements – should we express the super set of all of them, or the subset of only what they all share? Put like this, it’s obvious: the minimal set that all use cases share is not (generally) capable of supporting any of the individual use cases, and a specification that is minimal doesn’t work for any of them. So in practice, we produce standards that are half way in-between – not minimal or maximal – and in FHIR, we’re trying to be explicit about that.

Does that mean we don’t care about the minimal problem? No – the full HL7 methodologies for the various standards are capable of expressing the idea of minimum conformance – this is the minimum capability that you must have to be conformant. There’s a few problems with this though:

  • The capability for this is mostly lost in the overall complexity, and the tools to support it are poor
  • It’s not usually HL7’s business to force people to comply, so there’s often not a lot of point trying to capture this
  • It’s extremely difficult to capture this information

The consequence of this is that the minimal set is hardly ever expressed.

On that last point – it is extremely difficult to capture the information about the minimal set of shared requirements/use cases. It’s easy for an open community to capture use cases that aren’t handled – this can be expressed as “your standard doesn’t work for this use case” – a fault with the community product. But to capture the set of minimal agreement requires the members of the community to say something like “we don’t do this” – making it sound as if the fault is with the member. Very hard for a community to get it’s members to do, and vendors- and even providers – are extremely reluctant to do that (in fact, in practice, the decision to release that kind of information often has to be approved at the C-level). In FHIR, we’re setting up a special system to cater for gathering this kind of information through a trusted proxy so that there’s no possibility that observers will be able to trace information about the minimal set to any particular source, but it remains to be seen how well that will work.

Interoperability remains a tough problem.


#FHIR: Testing a new search mechanism

The FHIR search mechanism is based on the HTTP parameter mechanism – a series of named parameters with values. This works quite well for simple cases, but we’ve pushed it pretty far, and there’s a few cases for which we’ve had to invent some pretty tricky hacks to get things done (modifiers!). Here’s an example of a moderately simple search: find all the observations for patient with a name including “peter” that have a LOINC code 1234-5:

GET [base]/Observation?name=|1234-5&

The OData and SCIM specifications do search differently – a single http parameter “filter”, with it’s own search syntax. Following this pattern, the search would be:

GET [base]/Observation?filter=name eq|1234-5 and co "peter"

That alternative syntax has different strengths and weaknesses – it’s a little harder to get to to work (another syntax to deal with) but it’s also more capable, particularly at expressing nested related searches, which is the limitation of the existing approach. On the other hand, the existing approach is amenable to making up html forms fairly simply, and that’s not true of the filter based approach, so there’s always a price to pay for complexity.

But since implementers regularly ask why we don’t do search like OData/SCIM etc, I decided that for the connectathon this weekend, I’d add support for a _filter parameter (“_filter” not “filter” because of the way FHIR naming conventions work). Here’s how what I’ve implemented works:

  • A filter can be a logical one (x or x, or x and x, or not x)
  • A filter can contain other filters in a set of parentheses : “()”
  • A filter can be a test – path operation value, where operation is taken from the table below, and value is either a “true”, “false”, a JSON string, or a token (any sequence of non-whitespace characters, excluding “)” and “]”. Values are never case sensitive
  • A ‘path’ is a name, with chained searches done by etc as per existing source. There can also be a filter: name[filter].name…
  • The name is one of the defined search parameters that are used with the other search mechanism, with some special exemptions defined below.

Here’s some example filters:

  • Patient: name co “pet” – all patients with the characters “pet” in a given or family name
  • Patient: given eq “peter” and birthdate ge 2014-10-10 – all patients with a given name of peter, born on or after 10-Oct 2014
  • Observation: name eq|1234-5 – all observations with the loinc code “1234-5”
  • Observation: co “pet” – all observations on a patient with the characters “pet” in a given or family name
  • Observation: related[type eq “has-component”].target pr true – all observations that have component observations (note: this uses one of the search parameters defined for this mechanism, see below)
  • Observation: related[type eq has-component].target re Observation/4 – all observations that have Observation/v as a component

Note that the only difference between a “string” value and a “token” value is that a string can contain spaces and ) and ]. There is otherwise no significant difference between them.

Here’s the formal grammar for the syntax:

filter       = paramExp / logExp / ("not") "(" filter ")"
logExp       = filter ("and" / "or" filter)+
paramExp     = paramPath SP compareOp SP compValue
compareOp    = (see table below)
compValue    = string / numberOrDate / token
string       = json string
token        = any sequence of non-whitespace characters (by Unicode rules) except "]" and ")"
paramPath    = paramName (("[" filter "]") "." paramPath)
paramName    = ALPHA (nameChar)*
nameChar     = "_" / "-" / DIGIT / ALPHA
numberOrDate = DIGIT (DateChar)*
dateChar     = DIGIT / "T" / "-" / "." / "+"

Some additional notes about this:

  • Logical expressions are evaluated left to right, with no precedence between “and” and “or”. If there is ambiguity, use parentheses to be explicit
  • the compareOp is always evaluated against the set of values produced by evaluating the param path
  • the parameter names are those defined by the specification for search parameters, except for those defined below
  • the date format is a standard XML (i.e. XSD) dateTime (including timezone).

This table summarises the comparison operations available:

Operation Definition
eq an item in the set has an equal value
ne An  item in the set has an unequal value
co An item in the set contains this value
sw An item in the set starts with this value
ew An item in the set ends with this value
gt / lt / ge / le A value in the set is (greater than, less than, greater or equal, less or equal)  the given value
pr The set is empty or not (value is false or true)
po True if a (implied) date period in the set overlaps with the implied period in the value
ss True if the value subsumes a concept in the set
sb True if the value is subsumed by a concept in the set
in True if one of the concepts in the set is in the nominated value set by URI, either a relative, literal or logical vs
re True if one of the references in set points to the given URL

The interpretation of the operation depends on the type of the search parameter it is being evaulated against. This table contains those details:

Operation String Number Date Token Reference Quantity
Eq Character sequence is the same (case insensitive) Number is the same incl same precision Date is the same including same precision and timezone if provided Token is the same, including namespace if specified (case insensitive) n/a Unit and value are the same
Ne (same)————————————————————————————————————————————
Co Character sequence matches somewhere (case insensitive) An item in the set’s implicit imprecision includes the stated value An item in the set’s implicit period includes the stated value n/a n/a n/a?
Sw Character sequence matches from first digit (left most, when L->R) (case insensitive) n/a n/a n/a n/a n/a
ew Character sequence matches up to last digit (right most, when L->R) (case insensitive) n/a n/a n/a n/a n/a
gt / lt / ge / le Based on Integer comparison of Unicode code points of starting character (trimmed) (case insensitive) Based on numerical comparison Based on date period comparison per n/a n/a Based on numerical comparison if units are the same (or are canonicalised)
po n/a n/a Based on date period comparison per n/a n/a
ss n/a n/a n/a Based on logical subsumption; potentially catering for mapping between tx n/a n/a
sb n/a n/a n/a Based on logical subsumption; potentially catering for mapping between tx n/a n/a
in n/a n/a n/a Based on logical subsumption; potentially catering for mapping between tx n/a n/a
re n/a n/a n/a n/a Relative or absolute url n/a


  • For token, the format is the same as the existing search parameter. For convenience, the codes “loinc”, “snomed”, “rxnorm” and “ucum” are predefined and can be used in place of the full namespace

Additional Parameters

I needed to define some additional parameters in order to get this to work well. This table summarises the search parameters I added:

Resource Type Parameter Name Children
Observation related target = related-target

Type = related-type

Group characteristic value = value

code = characteristic

DocumentReference relatesTo code = relation

target = relatesTo

DiagnosticOrder event status = event-status
date = event-date
DiagnosticOrder item status = item-status

code = item-code

site = bodysite

event = item-event

DiagnosticOrder item-event status = item-past-status
date = item-date
actor = actor


  • Any time these names are used in a parameter, they must have a filter and a chained name under them
  • The first column is the resource type against which this name can be used
  • The second column is the name that is used
  • The third column defines the names that can be used in the chained parameter, and in the filter, and shows which existing search parameters they equate to
  • For example, you could search on Observation for related[type eq has-component].target re url. “type” here refers to the search parameter “related-type”, and “target” to the search parameter “related-target”. Note that the names are not always aligned like this – FHIR itself may be revised to make it so (a gForge task already exists to do so)


This is implemented on my server at, though the implementation has got some things that aren’t done yet (none of the really cool operations in “ss”, “sb” or “in”, for instance). Hopefully I’ll be able to fill some of these out by this weekend.

I’ve done this so that we can get a feel for how this approach works. It may become a candidate to add to the specification, either in addition to the existing search, or instead of it. I’m dubious about the second option though – what I’ve discovered about this search is that it isn’t degenerate, like the existing search – either you implement all the search, or you return an http error code. The existing search, you just add parameters in case they apply. That’s pretty useful, actually.



20 Questions for Health IT

“20 Questions for Health IT” is a project being run by Chad Johnson from

Beginning Tuesday, Sept. 2., we will begin publishing one health IT topic per day from 20 different individuals with a deep understanding of the topic. The author of each question was generous enough to stick her or his neck out and pose a short answer to the question in the hopes it will encourage further discussion in the comments section and also on Twitter using the #20HIT tag.

I’m honoured to be one of the 20 individuals. I’ve seen some of the topics that are coming, and it looks like it’s going to be pretty interesting. Hopefully Chad will post a summary for non-twitterers.