This wiki has undergone a migration to Confluence found Here
FHIR Connectathon 2
Revision as of 10:42, 6 December 2012 by GrahameGrieve (talk | contribs) (Created page with "== Introduction == This page describes the FHIR connectathon that will be held in the afternoon of Saturday Jan 12 and the morning of Sunday Jan 13 2013 in Phoenix (see http://ww...")
Introduction
This page describes the FHIR connectathon that will be held in the afternoon of Saturday Jan 12 and the morning of Sunday Jan 13 2013 in Phoenix (see http://www.hl7.org/events/wgm012013/).
Theme
XDS on Fire!
This connectathon is organised around the Xds-related suite of resources - XdsEntry(2), Person, Patient, XdsFolder. The purpose of this is two-fold: to test the suitability of the existing design for implementing XDS registries/repositories prior to IHE considering the resources, and because testing this functionality provides the coverage of the underlying issues that the FHIR project wished to see tested: general RESTful testing, pub/sub, batches, patient linking, and conformance statement/profiles
Registered Participants
- Health Intersections / Grahame Grieve. Actors: Document Repository, Xds Bridge + possible Patient demographics feed
Actors
- Document Registry
- this actor provides server support for patient, person, XdsEntry, XdsFolder resources. For a bonus, XdsEntry2 should also be supported
- Document Repository
- this actor adds support for binary handling to Document Registry (note: long term a repository would generate push notifications to a registry, but this is not required for this connectathon)
- Patient demographics feed
- This actor generates creates/updates/link/unlink for patient and person information (default for this, person and patient example resources from the specification)
- Document provider
- This actor pushes documents to a repository and/or a registry (for the purposes of the connectathon, the registry ignores binaries)
- XDS Bridge
- This is a document provider that functions by accepting XDS.b submission sets, and converting them to FHIR batches
- Patient Consumer
- this actor uses the patient/person information in a document registry to provide patient search/context
- Document Consumer
- this actor extends Patient Consumer to search, retrieve and display patient-related documents
Scenarios
Other References
- Last Connectathon: FHIR Connectathon (Sept.8, 2012)