This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "AID 201311 Minutes Amsterdam"

From HL7Wiki
Jump to navigation Jump to search
Line 59: Line 59:
 
#*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: 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.
 
#**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.
 
#Overview of RESTful DICOM (Rene Spronk)
 
#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 will speculate about future RESTful DICOM services as well as the relationship with HL7 FHIR.
 
#*DICOM has recently embraced new RESTful services for the exchange of image objects and metadata. This presentation will cover those services, and will speculate about future RESTful DICOM services as well as the relationship with HL7 FHIR.

Revision as of 11:13, 28 November 2013

This is the agenda of the "Application Implementation and Design" (AID, formerly known as RIMBAA) out-of-cycle meeting which is to be held on November 28th in Amsterdam. The meeting venue is kindly provided by Furore.

  • Date: November 28, 2013 (09:00-17:00)
  • Language: all presentations and discussions will be in English
  • Location: Furore offices, Amsterdam, @ Bos en Lommerplein 280, 1055 RW Amsterdam
  • Directions: in Dutch, and/or Google Maps
  • Registration: There is no registration fee. The size of the meeting room is limited however, so we urge you to please sign up by adding your name to the tail end of this page.

Minutes

Attendees:

  • 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, NL(afternoon)
  • Tom de Jong, Nova-Pro, NL
  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. 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 will speculate about future RESTful DICOM services as well as the relationship with HL7 FHIR.
  4. Implementation of search in a FHIR server (Martijn)
    • xx
  5. Approaches to Persistence on FHIR Servers (Andy Stechishin/Lorraine Constable, YouCentric, Canada)
    • Details to follow..
  6. Persistence of FHIR Resources using the MGRID RIM based database (Willem Dijkstra, Yeb Havinga)
    • Details to follow ..
  1. Discussion of "HL7 User groups" (Rene)