Difference between revisions of "AID 201411 Agenda"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
These are the minutes of the [[AID]] meeting to be held in Amsterdam on November 27th, 2014; one day after the [http://fhir.furore.com/devdays/ FHIR Developer Days] (inclusive of the FHIR connectathon) held at the same location.
+
[[category:RIMBAA Minutes]]These are the minutes of the [[AID]] meeting to be held in Amsterdam on November 27th, 2014; one day after the [http://fhir.furore.com/devdays/ FHIR Developer Days] (inclusive of the FHIR connectathon) held at the same location.
  
 
==Thursday Nov.27, 2014==
 
==Thursday Nov.27, 2014==

Revision as of 15:59, 2 December 2014

These are the minutes of the AID meeting to be held in Amsterdam on November 27th, 2014; one day after the FHIR Developer Days (inclusive of the FHIR connectathon) held at the same location.

Thursday Nov.27, 2014

Workgroup Date/Time Location Chair/Scribe
AID HL7 User Group, hosting FHIR 2014-11-27,
09:30-17:00
Amsterdam, the Netherlands Chair/Scribe: Rene Spronk

Attendees

  1. Ewout Kramer, Furore, NL
  2. Grahame Grieve, AU (12:00 onwards)
  3. Alexander Henket (12:00 onwards)
  4. Lloyd McKenzie, CA
  5. Rene Spronk, Ringholm, NL
  6. Patrick Pichler, AT
  7. Renato Calamai, eHealthTech srl, IT
  8. Dr.Ayman BafaQeeh, MOH, SA
  9. Theo Stolker, Vital Health Software, NL
  10. Sergej van Middendorp, Miles Ahead, NL
  11. Lorraine Constable, CA
  12. Patrick Loyd, US
  13. Ole Andreas Røsok, NO
  14. Marten Smits, NL

Agenda

  1. Administrative agenda items
    • Call to order by Rene at 09:44
    • Approval of the minutes of the Chicago WGM held in September 2014, available at AID 201409 Agenda.
      • MOTION to approve the minutes of the Chigaco WGM (Lorraine/Lloyd, 9-0-1) (y-n-abst)
    • Approval of the new DMP
      • Rene briefly presents the differences between the 'default' DMP and the proposed AID DMP.
      • MOTION to approve the DMP as presented (Patrick/Lorraine, 9-0-1) (y-n-abst)
  2. The Dutch National e-Mental Health Exchange (“Koppeltaal”) is on FHIR! (Sergej van Middendorp/Theo Stolker, NL, see http://www.hl7.org/documentcenter/public/wg/java/2014-11-27%20Koppeltaal%20AID%20Presentation.pptx for presentation and https://vimeo.com/113370865 for a video capture of the presentations)
    • There are clear benefits of e-Health treatment in Mental Health. Each Mental Health Clinic has started initiatives to enable eHealth, causing a lot of duplicated efforts. Due to the absence of good standards, a lot of money is spent on integrating the various portals with e-Health Games and Interventions. Koppeltaal is an initiative that proposes an exchange standard based on HL7 FHIR Messages to address this integration issue. As we speak, we are implementing a central hub (“Koppelbox”) that allows portals and e-Health interventions to cooperate in the delivery of e-Mental Health to a wider patient audience.
  3. Validation of FHIR Resources (Ewout Kramer, Furore, NL)
    • Validation of FHIR Resources using the Profiles requires many moving pieces: Access to the base definitions of the core Resource, retrieval of external valuesets and other profiles. You have to be able to execute invariants formulated in XPath and produce a sensible output so the users knows where validation failed. We will discuss how we implemented this in the C# reference implementation.
    • Furore wrote a profile validator as part of the .NET reference implementation. There are (semi) frequent talks between HAPI and .Net API keeps their API on par. To validate your profiles you need a full stack with lots of moving parts
      • Base: You need a parser for FHIR
      • You need all the metadata, access to the FHIR source definitions
      • You need logic to navigate through the hierarchical structures of the resources and be able to jump between type boundaries
    • The validation.zip file ([1](http://hl7.org/implement/standards/fhir/downloads.html)) has all the generated schemas. validation.zip contains all files necessary to validate your profiles:
      • Profile-resources.xml is an atom feed that has all base-profiles for all the individual resources
      • Profiles-datatypes.xml is an atom feed with all the profiles for the datatypes
      • Is also contains the "core" value sets in atom feeds
    • First step is to build a system that gets you the base definitions, profiles, and value sets. For .NET you can use the ArtifactResolver.cs to find the base definitions and value sets online and CoreZipArtifactSources.cs and FileArtifactSource.cs can find the definitions locally in validation.zip
    • For DSTU-2, Structure and extension definition will separated from profile and become individual resources:
      • Conformance package will be the name of the package that contains these structure and extension definitions.
      • Differential profiles looks like profile, but doesn't contain all the information anymore, but only contains the changes you made compared to the base definition.
      • The validator needs all information - not only the differential. You can use the expander in the .net and java api to expand you differential profile and create the full profile or "snapshot version" of the profile.
      • The differential profile is useful for developers, seeing chances and perhaps create release notes.
    • Xpath Navigation - .net Navigator can move through the whole definition. The actual validator is now pretty simple:
      • The ```XpathNavigator``` navigates through the instance and profile: The current node gets compared to the current node in the profile.
      • XpathNavigator in .net can't navigate through json, but Ewout wrote a ```JsonXpathNavigator``` that handles Json like it's XML, so like could even do XSLT and Xpath on Json.
      • All classes can be found in the .Net API.
      • The validation gives you clear error messages what's wrong with your profiles, including line numbers, description, severity etc.
    • You can expand validate your DSTU-1 profiles on [fhir.furore.com](http://fhir.furore.com/resource/provide?action=validate)
  4. Discussion: Persisting FHIR Resources
    • One of the issues that FHIR itself is silent on is Persisting FHIR Resources. This depends on the context and purpose of use, but one can probably come up with some general guidelines with regards to best practices related to the persistance of resources. The aim of this free flowing discussion is to create the 'backbone' of a future whitepaper that documents the best practices around persistence.
  5. Formation of the FHIR "community"
    • how do we structure the group that exists outside the HL7 community
  6. FHIR Page on Wikipedia
  7. Adjournement