This wiki has undergone a migration to Confluence found Here

AID 201311 Minutes Amsterdam

From HL7Wiki
Revision as of 13:23, 28 November 2013 by Rene spronk (talk | contribs)
Jump to navigation Jump to search

These are the minutes of the "Application Implementation and Design" (AID, formerly known as RIMBAA) out-of-cycle meeting which was held on November 28th in Amsterdam. The meeting venue was kindly provided by Furore.

Workgroup Date/Time Location Chair/Scribe
AID HL7 User Group 2013-11-28,
Amsterdam, NL Chair/Scribe: Rene Spronk


  • Rene Spronk, Ringholm, NL (chair/scribe)
  • Michael van der Zel, UMCG, NL
  • Ewout Kramer, Furore, NL
  • Andy Stechisin, YouCentric, CA
  • Lorraine Constable, YouCentric, CA
  • Hans Vonkeman, Furore, NL
  • Henk Enting, MGRID, NL
  • Mitchell Duim, Results4Care, NL
  • Willem Dijkstra, MGRID, NL
  • Roberta Gazzarata, University of Genoa, IT
  • Mauro Giacomini, University of Genoa, IT
  • Bas van Poppel, HL7 NL
  • Bertil Reppen, Apertura,NO
  • Albana Gaba, Portavita, NL
  • Tom van der Weide, Portavita, NL
  • Adri Burggraaff, HL7 NL, (afternoon)
  • Martijn Harthoorn, Furore, NL (afternoon)


  1. Administrative agenda items
    • Approval of the minutes of the previous meeting
      • xxxx Atlanta
      • xxxx Combridge
    • Approval of updated DMP
      • Motion to approve the version as distributed (Lorraine, Andy, 10-0-0)
    • Question by ITS regarding the RIM ITS
      • Andy: ITS going thru outstanding items. RIM based ITS has been sitting there, not formally published. No questions from other parties about it. Is this still relevant?
      • Ewout: I know I used is, as did Michael. Rene: only relevant to those that really use a RIMBAA approach. Andy: it was balloted as DSTU, comment was that there should be examples. There are no known (active) implementers. Rene: create a whitepaper, but make sure there is a XSD schema.
      • To do for Ewout/Lorraine: find XSD for RIM ITS
    • Next European AID out-of-cycle
      • Rene: Next to the FHIR Dev Days in November? The previously planned event in the Netherlands was in Eindhoven, but that meetings' focus is only on the Netherlands.
      • Andy: apps4health at Mohawk in May, we'll have an AID in conjunction with that.
      • Rene: maybe hold a Dutch-language event in June, and an English one in November.
      • Andy: involve affiliates, their focus is also on implementation.
    • Review and approval of the agenda
      • Approved by general consensus
    • Permission to record video
      • Rene requests persmission to record part of the meeting on video. Approved by general consensus without objections.
  2. FHIR Implementation Aspects (Ewout Kramer, Furore)
    • Ewout kicks off with a brief introduction of FHIR, to get those with little knowledge of FHIR up to speed. Concept of a Resource, extensions, bundles, generated APIs and reference implementations.
    • Architecture: HTTP/REST interface, hands bundled entries to a FHIR service. This communicates with the Indexer/Search (a search engine) and a Storage component.
      • Storage component stores bundled entries (a bundle is effectively a transactional concept in FHIR). They support versioning, which means that a new bundle is just inserted in the database. Uses MongoDB, so it serialzes the feed into JSON, then store it. Mongo doesn't have transactions, so to mark versions as current/old is tricky, this is a non-atomic operation.
      • Also has 'snapshot' of all (version specific) resource identifiers at a certain point in time - a query is done on a particular set of resources as it existed at a particular point in time.
      • FHIR Service implements the various operations. Search parameter conversion. Operation outcome serialized by to HTTP/REST frontend.
    • Bundles (e.g. Documents) may contain 'cid:' style references, which will need to be resolved prior to storing a local copy of a resource, one has to create/generate a local id prior to storing the reources locally. Resource identifiers are technical identifiers (dependant on the storage location) - they're not part of the actual resource data.
      • Or, as a receiver, try and locate a pre-existing resource that has a 'business-identifier' that's the equivalent of the resource that has just been received. Use a reference that resource instead of the 'cid:' reference.
      • Furores FHIR Server component includes a 'identity resolver' to deal with this (inbound as well as outbound)
      • Ewout: this code will be open sourced, from January 2014 onwards. Michael: can I change the coe to use a SQL Server database? Ewout: yes, certainly, lots of work, but can be done. Support for history has lots of impact, if you want to implement that.
    • Bas: order comms to laboratory scenario. Andy: maybe no server, two directional push of resources. Or a server where the lab system could subscribe to an order feed, order management system publishes orders to that same server. Or put a FHIR facade on the old v2 interfaces.
      • Bas: in old messaging scenario, desire is to have in-order delivery. Ewout: we use Atom for multiple things: packaging (serialization), and use it in REST to provide a subscription mechanism. Atom explicitely has no order. Order placer needs to sent orders in-sequance. Burden (because Atom by definition doesn't define a particular sequence) is on the client (order filler) to sort (sequenced in time) the orders as present in the Atom feed. FHIR is however silent on how one should do this, for it marries two different exchange paradigms.
      • Tom vdH: why isn't a transaction a Resource? Ewout: well, we're getting there, working on a Composition resource, akin to openEHR Composition. Include it in all transactions.
  3. Implementation of search in a FHIR server (the SPARK serach engine) (Martijn Harthoorn, Furore, Netherlands)
    • Martijn: search engine also uses MonogDB, but a different set of collections. Search engine consists of 2 parts: searching and indexing. FHIR has the design goal that clients should be easy, dealing with queries is a complex server-side component. Search possibilities are exponential (combinatorial logic between multiple parameters).
      • Build it according to specs, or build it as we assume that a user has understood the specification? We deviated from the standard quite consciously in some aspects. Initially tried a code based solution, snippet of code for each and every search parameter, tried to crawl the resources upon receipt of the query, way too slow. Ewout suggested indexing as an approach, tried to use Lucene first (but there were issues with it on .net; and it's mainly focused on text searches which is not applicable here, and the possibility in FHIR to query based on the existence of missing attributes), then an own indexing engine (the index is stored in a dedicated MongoDB collection), led to fast search.
      • Indexing has 4 steps: harvest the resource (fetch bits relevant for indexing), determine data type, groom (pre-process) the data, store data in index.
      • When indexing, some referenced resources may not be located on the same server. So one could imagine things like distributed indexing - which will be an interesting challenge.
      • Transform flat list (query URL) in an expression tree (like: give me all documents for patients called Smith). Join [of result sets] is not executed at the MongoDB side (MongoDB doesn't support joins), but on the client [in this context: the FHIR Server].
      • Andy: so we've graviated away from a Google-like search on Resources (as defined in the early versions of FHIR) to a IT-formal type of querying? is that because we (as developers) are used to think that way? Ewout: just trying to do what most clients need. May add a query language for queries that are not expressable as a URL. Intent is not to invent an own query language. OQL perhaps, although that adds a level of complexity that may not be desirable.

  1. Approaches to Persistence on FHIR Servers (Andy Stechishin/Lorraine Constable, YouCentric, Canada)
    • Details to follow..
  2. Persistence of FHIR Resources using the MGRID RIM based database (Willem Dijkstra, Yeb Havinga)
    • Details to follow ..
  1. Overview of RESTful DICOM (Rene Spronk)
    • DICOM has recently embraced new RESTful services for the exchange of image objects and metadata. This presentation will cover those services, and covers the relationship with HL7 FHIR and IHE MHD.
      • Both IHE as well as DICOM representatives regularly take part in FHIR meetings, a mapping of DICOM and FHIR is already included in the FHIR specification.
  1. Discussion of "HL7 User groups" (Rene)