Difference between revisions of "AID 201311 Minutes Amsterdam"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
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 [http://www.furore.com Furore].
+
[[category:RIMBAA Minutes]]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 [http://www.furore.com Furore].
 
 
  
 
{| border="1" cellpadding="2" cellspacing="0" style="background:#f0f0f0;" width="100%"
 
{| border="1" cellpadding="2" cellspacing="0" style="background:#f0f0f0;" width="100%"
Line 11: Line 10:
 
|'''AID HL7 User Group'''||2013-11-28, <br/>09:00-17:00||Amsterdam, NL||Chair/Scribe: Rene Spronk
 
|'''AID HL7 User Group'''||2013-11-28, <br/>09:00-17:00||Amsterdam, NL||Chair/Scribe: Rene Spronk
 
|}
 
|}
 
 
==Attendees==
 
==Attendees==
 
*Rene Spronk, Ringholm, NL (chair/scribe)
 
*Rene Spronk, Ringholm, NL (chair/scribe)
Line 33: Line 31:
 
#Administrative agenda items
 
#Administrative agenda items
 
#*Approval of the minutes of the previous meeting
 
#*Approval of the minutes of the previous meeting
#**xxxx Atlanta
+
#**Motion to approve the minutes of the Atlanta meeting, as available at [[RIMBAA 201305 WGM Minutes Atlanta]] (Andy, Ewout, 17-0-0)
#**xxxx Combridge
+
#**Motion to approve the minutes of the Cambridge meeting, as available at [[RIMBAA 201309 Agenda]]. (Andy, Rene, 17-0-0)
 
#*Approval of updated DMP
 
#*Approval of updated DMP
 
#**Motion to approve the version as distributed (Lorraine, Andy, 10-0-0)  
 
#**Motion to approve the version as distributed (Lorraine, Andy, 10-0-0)  
Line 69: Line 67:
 
#**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.
 
#**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].   
 
#**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].   
 +
#**Discussion around availability of new resources in searches. There may be cloud based environemts where a delay between visibility in an App of a newly created resource somewhere else is perfectly acceptable (say: 10 minutes), whereas an environment within 1 hospital may well require near real-time updating.
 
#**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.
 
#**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.
 +
#Approaches to Persistence on FHIR Servers (Andy Stechishin/Lorraine Constable, YouCentric, Canada)
 +
#*FHIR is about communications, what are the options for persistence? Presentation is a work in progress, ultimate goal is to create an AID whitepaper which can go out for 'ballot for comment'
 +
#*Three main approaches, compare and contrast, FHIR Extensions a key issue.
 +
#*#NoSQL (e.g. MongoDB, Cassandra, Couch). Idea being that you're not doing tradional SQL, and that they're very scalable. JSON syntax popular. Seems to align well with FHIR, particularly when using JSON. Resource serialization is trivial. No standard query language however. Fluid structure makes it difficult to enforce local business/integrity rules - who needs that when you web-scale?.
 +
#*#*XML Databases are (can be) and example in this category.
 +
#*#*Best fits: resource brokering applications, store and forward (transient), snapshotting. Ewout: use case much be about large volumes / clouds of data. That's where you move into this space. Point is not just to store things, but to query text blobs. 
 +
#*#Name-value pairs, relational database, SQL patterns. Tried and tested, well known. Efficient querying. Future proof against any new extensions. Queries can be extremely difficult. Large amount of up-front analysis to correct set the extension / ficed column boundary.
 +
#*#*Best fits: in-depth data analysis, flexibility and growth, pulling the original resource out is low priority.
 +
#*#Relational Hybrid - NoSQL combined with Relational DBs - store extra stuff using extended types. Like having an XML (or: JSON) column in a relational database. Rapid queries, ability to preserve original extended structures, query capabilities into those extensions.
 +
#*#*When amix of analaysis with transactional get/put; large mix of resources from multiple sources need correlated; applications needs to harvest key elements but wishes to retain the resource in a reproducable form.
 +
#*Discussion about persisting the version number of a Resource - in case one has to update the structure of the persisted resources. depends on ones viewpoint
  
 
#Approaches to Persistence on FHIR Servers (Andy Stechishin/Lorraine Constable, YouCentric, Canada)
 
#*Details to follow..
 
 
#Persistence of FHIR Resources using the MGRID RIM based database (Willem Dijkstra, Yeb Havinga)
 
#Persistence of FHIR Resources using the MGRID RIM based database (Willem Dijkstra, Yeb Havinga)
 
#*Details to follow ..  
 
#*Details to follow ..  
Line 80: Line 87:
 
#*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.
 
#*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.
 
#**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.
 
+
#Discussion of "HL7 User groups"  
#Discussion of "HL7 User groups" (Rene)
+
#*
 +
#Meeting adjourns at 17:00

Revision as of 14:12, 28 November 2013

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,
09:00-17:00
Amsterdam, NL Chair/Scribe: Rene Spronk

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, (afternoon)
  • Martijn Harthoorn, Furore, NL (afternoon)

Minutes

  1. Administrative agenda items
    • Approval of the minutes of the previous meeting
    • 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].
      • Discussion around availability of new resources in searches. There may be cloud based environemts where a delay between visibility in an App of a newly created resource somewhere else is perfectly acceptable (say: 10 minutes), whereas an environment within 1 hospital may well require near real-time updating.
      • 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.
  4. Approaches to Persistence on FHIR Servers (Andy Stechishin/Lorraine Constable, YouCentric, Canada)
    • FHIR is about communications, what are the options for persistence? Presentation is a work in progress, ultimate goal is to create an AID whitepaper which can go out for 'ballot for comment'
    • Three main approaches, compare and contrast, FHIR Extensions a key issue.
      1. NoSQL (e.g. MongoDB, Cassandra, Couch). Idea being that you're not doing tradional SQL, and that they're very scalable. JSON syntax popular. Seems to align well with FHIR, particularly when using JSON. Resource serialization is trivial. No standard query language however. Fluid structure makes it difficult to enforce local business/integrity rules - who needs that when you web-scale?.
        • XML Databases are (can be) and example in this category.
        • Best fits: resource brokering applications, store and forward (transient), snapshotting. Ewout: use case much be about large volumes / clouds of data. That's where you move into this space. Point is not just to store things, but to query text blobs.
      2. Name-value pairs, relational database, SQL patterns. Tried and tested, well known. Efficient querying. Future proof against any new extensions. Queries can be extremely difficult. Large amount of up-front analysis to correct set the extension / ficed column boundary.
        • Best fits: in-depth data analysis, flexibility and growth, pulling the original resource out is low priority.
      3. Relational Hybrid - NoSQL combined with Relational DBs - store extra stuff using extended types. Like having an XML (or: JSON) column in a relational database. Rapid queries, ability to preserve original extended structures, query capabilities into those extensions.
        • When amix of analaysis with transactional get/put; large mix of resources from multiple sources need correlated; applications needs to harvest key elements but wishes to retain the resource in a reproducable form.
    • Discussion about persisting the version number of a Resource - in case one has to update the structure of the persisted resources. depends on ones viewpoint
  1. 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.
  2. Discussion of "HL7 User groups"
  3. Meeting adjourns at 17:00