Difference between revisions of "Talk:Mobile access to Health Documents - Supplement revision 2"

From IHE Wiki
Jump to navigation Jump to search
Line 169: Line 169:
 
** We should ask the FHIR core team to review our proposed service
 
** We should ask the FHIR core team to review our proposed service
 
** Could leverage MHD original Provide transaction
 
** Could leverage MHD original Provide transaction
 +
 +
=November 7, 2014=
 +
Attendees: John Moehrke, Bill Majurski, Dave Franken, Dave Pyke, Denise Probst, Eric Heflin, Paul Lomayesva, Peter Bernhardt, Rob Horn, Walco van Loon, Eric Heflin
 +
 +
Notes:
 +
* FindDocumentReferences is sketched out, but many deep details are left as TODO (marked with comments).
 +
* ProvideDocumentReferences has made little improvement
 +
 +
 +
* Concern around FHIR conformance
 +
** concern regarding unique identifiers and when they need to be deferencable.
 +
** http://www.hl7.org/implement/standards/fhir/xml.html#atom-notes
 +
 +
* Note that FHIR in DSTU2 will be replacing the Atom based bundle with a bundle that is not based on Atom
 +
** Which also moves metadata
 +
 +
* Bill
 +
** Has commitment  for Connectathon for FindDocumentReferences.
 +
** Theory is that FindDocumentReferences and FindManafests can be executed against a otherwise normal FHIR server, provided magic happened to get the resources there.
 +
 +
* Urgency because of connectathon to make sure the examples for ProvideDocumentReferences is as good as possible.
 +
** http://wiki.ihe.net/index.php?title=MHD_Implementation_Guide#Provide_Document_Resources_.28ITI-65.29
 +
 +
* There are some Change Proposals proposed to FHIR DSTU1 for fixing items
 +
** [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3728 #3728 Replace Atom with a FHIR specific bundle that is not based or constrained by Atom]
 +
** [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3452 #3452 DocumentReference should include practiceSettingCode ]
 +
** [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3213 #3213 DocumentReference author needs to be multiple]
 +
** [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=2972 #2972 DocumentReference.description be renamed to DocumentReference.title for consistency with Composition.title]
 +
** [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3281 #3281 better description of hash]
 +
** [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3359 #3359 documentreference should support structured]
 +
 +
*Connectathon
 +
** Will soon send out the call for participation draft.

Revision as of 10:01, 7 November 2014

October 24, 2014

attendees:

  • John Moehrke
  • Bill Majurski
  • Walco van Loon
  • Lynn Felhofer
  • Alex Lippitt
  • Dave Franken
  • Chris Stehno
  • geojaya
  • Mick Talley
  • Mauro
  • Mohammad Jafari (VHA, ESC)
  • Rinil
  • Eric Heflin (THSA)

notes:

  • Justin is too busy to help, so John will mock up the FindDocuments transaction
    • Please review critically
  • Walco
    • has mocked up Provide Document resources transaction
    • This was discussed on the call
    • Question: Is the grouping behavior between MHD and XDS clear enough? Would a MHD publisher expect the results to show in XDS?
      • This should already be defined in Volume 1 under grouping behavior.
      • Does this need correction or elaboration?
    • Question: Should we support Provide transactions to already published binary documents?
      • Yes, this is just a fully qualified URI rather than a internal-to-the-bundle relative URI
    • What would the return result on a success look like?
      • Would it just return the documentmanafest ID?
      • would it be a list of all resources created?
    • Is an interest in help from Dave Pyke to do technical writing on this transaction
  • Bill
    • No time to work on spec, but working on tooling
      • Tooling deadline is Dec 15th
      • using the java tooling from the FHIR spec
        • means we get xml vs json translation free
      • Will have tooling to do metadata validation (Resource content)
      • Not likely to have source available in the short time
    • Will there be test data?
      • Yes, bill can take existing test data and make it available
  • Mick
    • Michigan is prototyping RESTful access to their HIE. They are following the IHE specifications as much as possible
    • Mick asks what about Security and Privacy?
    • John - we have that in IUA
      • We have a few vendors signed up for PDQm
      • No one has signed up for IUA
    • some Resources regarding Security and Privacy and the MHD profile
  • Eric
    • New Directions
    • Going to follow upon the success last year with HPD work
    • IHE-USA is the sponsor
    • Should we setup an independant call to plan virtual connectathon?
      • Will use this timeslot, taking the last 30 minutes or more if technical gets done early
    • Virtual connectathon is open to ALL, not limited to connectathon participation
    • Roadmap of Milestones
      • Create a basecamp for the virtual connectathon
        • Was used for HPD last year, seems people willing
      • Will reach out to find greater participation
      • Connectathon participation might be limited to a small number, like 6
    • I would like to use the MHD Status page as the front-door.
      • So add the basecamp to that page

September 12, 2014

attendees:

  • John Moehrke
  • Bill Majurski
  • Justin Fyfe
  • Karen Witting
  • Dragon
  • Sungkee Lee
  • Walco van Loon
  • Ben Kraufmann
  • Lynn Felhofer

Notes

  • Justin
    • will be able to provide a few hours a week under a new contract he has with OpenHIE
    • Will be at HL7 FHIR Hackathon
  • John has gotten no progress
    • Will be at HL7 FHIR Hackathon
  • Bill
    • has been working on a few of the key difficult attributes and how to translate (e.g. URI)
    • Working on the example. Need to validate that it fits spec, and that spec fits the example
      • We can rely on the HL7 FHIR code-base to do the XML to JSON format translations
      • concept of "code first". Try to have a reference system and test tooling, that will help drive spec accuracy
      • cleaning up the wiki page for attribute mapping
    • Will not be at Hackathon, but will be at HL7 meeting
  • Walco
    • has been working on the Provide transaction
    • Not liking the Mailbox model, likely will end up using it
    • Concern around FHIR principle of everything being a referencable
      • Discussion: We can and should use the 'contained' concept of FHIR when we really need it (e.g. PatientSourceInfo)
    • Mailbox issues
      • it is a very underspecified thing
      • therefore conformance is really only testable with a profile
      • note we can add transactional behaviors to core mailbox behavior
      • What is the difference between Transaction and Mailbox?
        • Walco: Message exchange pattern (messaging, REST, mailbox)
      • John: I think there is a concept of "Transaction" that is being developed. It is not well exposed to the broader community.
      • John: Lets just focus on Mailbox only as a way to allow us to focus on the bundle content and encoding inside the transaction. We will likely use a totally newly invented URL for our Provide endpoint. It will have as many characteristics from FHIR as we can take, but will not likely be a FHIR endpoint.
    • Will work on the Provide trasaction. Focus first on the bundle content profiling. secondary on HTTP transactional characteristics.
  • Gila has forwarded the shortened MHD supplement to Mary for publication on the external www.ihe.net web site.

February 28, 2014

attendees:

  • John Moehrke
  • Bill Majurski
  • Eric Heflin
  • Mauro Zanardini
  • Rob Horn
  • Gila Pyke

Topics:

  • Reveal Wiki page and work through operating mechanism
  • Attribute Mapping - Bill
    • Author cardionality mismatch
      • might be deeper solution
    • architecture difference
    • Bill to post link to google document he is using for tracking
    • analysis doing broad assessment first, starting with XDS focus
  • Scope - John
    • have not done
  • Provenance Resource - Rob
  • Transport Pattern -- Walco
    • Noted FHIR has concept of many transports, but HTTP REST is only one clear
    • looking into other
    • Will focus on Publishing including multiple documents and submission sets.
    • should also look into defining this simply as a service that invokes FHIR resources
    • Note that a "Profiling" tool is being developed. Not clear if it is accepted inside of HL7 FHIR yet.
  • FHIR vs IHE lifecycle
    • See W3C discussion

October 10, 2014

Attendee: John Moehrke, Bill Majurski, Elliot Silver, Jim McInnis, Karen Witting, Laura Bright, Lynn Felhofer, Peter Bernhardt, Walco van Loon, Derrick Evans,

Topics:

  • FHIR DSTU2 is going to be delayed. So we should continue to focus on using DSTU1
    • This will allow IHE-HL7 workgroup to be created and better support us inside HL7
    • This will allow us to focus on DSTU1, while evolving DSTU2
    • We should focus on IHE profiling, thus not trying to us the FHIR Profile or Conformance resources
    • We will need to use FHIR extensions as needed for our work.
  • Connectathon
    • Minimal support will be available for "New Directions" (aka Hackathon)
    • Bill is looking for a java implementation that he can standup for connectaton use
  • Provide and Register
    • Walco has provided an example published through a google document link
    • We should spend more time on the bundle content definition
    • Given the current direction we should focus on creating a new service. This will not be usable with existing FHIR servers.
    • We should ask the FHIR core team to review our proposed service
    • Could leverage MHD original Provide transaction

November 7, 2014

Attendees: John Moehrke, Bill Majurski, Dave Franken, Dave Pyke, Denise Probst, Eric Heflin, Paul Lomayesva, Peter Bernhardt, Rob Horn, Walco van Loon, Eric Heflin

Notes:

  • FindDocumentReferences is sketched out, but many deep details are left as TODO (marked with comments).
  • ProvideDocumentReferences has made little improvement


  • Note that FHIR in DSTU2 will be replacing the Atom based bundle with a bundle that is not based on Atom
    • Which also moves metadata
  • Bill
    • Has commitment for Connectathon for FindDocumentReferences.
    • Theory is that FindDocumentReferences and FindManafests can be executed against a otherwise normal FHIR server, provided magic happened to get the resources there.
  • Connectathon
    • Will soon send out the call for participation draft.
Retrieved from "http://wiki.ihe.net/index.php?title=Talk:Mobile_access_to_Health_Documents_-_Supplement_revision_2&oldid=81358"