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

AID 201311 Minutes Amsterdam

From HL7Wiki
(Redirected from AID 201311 Agenda)
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,
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
    • 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. The presentation wasn't based on a powerpoint.)
    • 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 search engine) (Martijn Harthoorn, Furore, Netherlands, see http://www.hl7.org/documentcenter/public/wg/java/20131130_FHIR_search.pptx for slides)
    • 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, see http://www.hl7.org/documentcenter/public/wg/java/20131130_AID-FHIR-Persistence.pdf for slides)
    • 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.
    • Rene: how about dual approaches? Using a OLAP and OLTP approach? Andy: we'll need to cover that in the whitepaper. Rene: and Graph absed databases, admittedly an academic option, but could be a fit.
    • Bas (partly tongue in cheek): FHIR persistence in MUMPS ? Ewout: didn't Cache come out of MUMPs ?
    • Sense of the room is that we should progress this material towards a balloted whitepaper.
  5. RIM for (F)HIRe (Willem Dijkstra, Henk Enting, see http://www.hl7.org/documentcenter/public/wg/java/20131130_mgrid-fhir.pdf for slides)
    • The RIM is cool. Objective of MGRID is to reason about medical data in a temporal context, from many sources. Requires to store data in one common data model.
    • Coming from the RIM, looking at FHIR: in v3 there are no operations on data (whereas they exist in FHIR). Most v3 tools are pretty bad (whereas they exist for FHIR). Resource definitions map back to the RIM.
    • Is it possible to create a FHIR interface, but map to v3 in our common model, to be used by our reasoner.
    • Uses a FHIR PUT Organisation as an example. Created a v3 model that corresponds with it. Create a translation from FHIR to v3 expression - v3 XML tends to be smaller. (side note: certain things don't map well to the II data types, current mapping ignores extensions). Translate to SQL statement to update database.
    • Mapping FHIR to v3 'needs some work'. Need a mapping from FHIR to R1/R2 datatypes. Attribute mappings (as specified in the FHIR spec) are unfinished.
    • Henk is willing to add their mappings to the FHIR spec. Ewout: we're looking for uses cases, and interested parties to add mappings. Lorraine: mapping an issues, bacause sometimes there are multiple possible mappings.
    • Approach v2 in the same manner, transform v2 to v3 model, update database.
    • Ultimate goal is to reason on a (RIM-based) data warehouse.
  6. Overview of RESTful DICOM (Rene Spronk, Ringholm, see http://www.hl7.org/documentcenter/public/wg/java/20131130_HL7_FHIR_IHE_MHD_DICOM_RESTful.pdf for slides)
    • 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.
  7. Discussion of "HL7 User groups"
    • Rene explains some of the background
    • The users have the ability to influence the standards, this is a role of a user group. E.g. comments on the implementability of FHIR.
    • Andy: we could be more active in representing the community.
    • Lorraine: user group: trade experiences. Ewout: getting presentations of other developers. Bas: persentations about using and implementing the standards (e.g. IHIC CDA-around-the-world)
    • User questions: FHIR is on Stackoverflow, and has a HL7 listserv.
    • Andy: F2f meetings help to explore connections to follow up via e-mail. Interactive format pereferred.
    • Open for non-members as a marketing instrument, not a revenue generation mechanism.
    • Willem: some user groups are not even affiliated with the organization/product they're focused on
    • Lorraine: relationship with Helpdesk functionality as recently introduced by HL7 International
    • Andy: we need to show benefit of the user group to the decision makers, those that decide whether or not someone is allowed to show up.
    • Ewout: being a HL7 user group may be of help in terms of marketing to new participants (in AID meetings).
    • Andy: When our meeting gets bigger, it needs more organization, will have to charge for the meeting. Andy: having a fee will also lead to different expectations
    • Ewout: document prerequisites to atting a user group meeting
    • Have (paid for) educational sessions, followed by an open (and free/nearly free) user group meeting.
  8. Meeting adjourns at 16:45

Photo

AID User Group Meeting, Nov. 28 2013
Retrieved from "https://wiki.hl7.org/w/index.php?title=AID_201311_Minutes_Amsterdam&oldid=80670"