This wiki has undergone a migration to Confluence found Here
Difference between revisions of "FHIR Connectathon 1"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| Line 6: | Line 6: | ||
= General Comments = | = General Comments = | ||
The aim of this initial connectahon is to test the infrastrutural components of FHIR (mainly: its REST interface and Profiles), using a few relatively stable Resources. | The aim of this initial connectahon is to test the infrastrutural components of FHIR (mainly: its REST interface and Profiles), using a few relatively stable Resources. | ||
| − | * There will be extensions, applications should be able to share stuff with other applications whose extensions you don't understand | + | * There will be extensions, applications should be able to share stuff with other applications whose extensions you don't understand. Systems should have a) capacity to ignore unknown extensions, b) (for server applications) capacity to store unknown extensions and reproduce them faithfully |
* All participating applications should play the role of at least one of the Person actors (see below) | * All participating applications should play the role of at least one of the Person actors (see below) | ||
Revision as of 07:20, 24 May 2012
Contents
Event Planning
A FHIR Connectathon will be held on Baltimore USA on Saturday September 8th, 2012. The connectathon is sponsored by the RIMBAA WG, all FHIR implementers are welcome to join in the event.
General Comments
The aim of this initial connectahon is to test the infrastrutural components of FHIR (mainly: its REST interface and Profiles), using a few relatively stable Resources.
- There will be extensions, applications should be able to share stuff with other applications whose extensions you don't understand. Systems should have a) capacity to ignore unknown extensions, b) (for server applications) capacity to store unknown extensions and reproduce them faithfully
- All participating applications should play the role of at least one of the Person actors (see below)
Scenarios
During the connectathon 3 types of workflows will be tested: the creation and exchange of Profiles, Persons and Labreports.
Resource Profiles
Actors:
- Profile Author
- Allows for the creation (mandatory) and modifification (optional) of profiles, has the capacity to send these profiles to the Profile Server
- Note: modification requires that this Actor be grouped with the Profile Consumer actor.
- Profile Server
- Provides a repository of Profiles; provides a RESTful service (per FHIR spec) for Profiles (i.e. providing all service operations for Profiles, inclusive of queries).
- Profile Consumer
- Provides user access to profiles on Profile Server (find/retrieve). The information flow is in one direction only: Profile Server to Profile Consumer.
Scenario:
- system analyst A defines a profile on a Person resource
- submits it to a Profile registry
- Implementer B searches for Profile, and accesses it
Person
See persons
Actors
- Person Demographics Consumer
- queries, id to demographics, partial demographics to list of candidates
- Note: this Actor is grouped with the Profile Consumer actor.
- Person Demographics Server
- responds to queries
Scenario
- ?
LabReport
The LabReport scenario has been deliberately kept as simple as possible.
- For LabReport, applications SHOULD not implement <admission> and <clinicalinfo>; applications processing the LabReport MAY ignore these elements. The <requester> SHALL be an Organization resource.
- Note: Specimen and Organization resources to be documented prior to the connectathon.
Actors
- LabReport Author
- LabReport Server
- LabReport Consumer
