Clinical Connectatathon 1 Tooling

This is a set of notes about the tooling to support the clinical connectathon.

Overall Context

The PC committee has prepared a list of scenarios. As a "clinical connectathon" we are testing how systems/practitioners connect using FHIR. So each scenario will have one of more associated "exchange points" where the clinical connectathon participant either:

• prepares a logical package of content that will be sent from one system to the next
• reviews and comments on the logical package of content that someone else sent

We expect two kinds of outcomes from the connectathon:

• identification of areas where clinical standardisation should be prioritised
• identification of areas where the FHIR specification is deficient

tooling design

The tooling should support the work flow above, with a general workflow something like this:

• the user logs in
• they choose one of the scenarios
• they choose one of the defined exchange points
• the decide whether:
  • to create a new package as a sender (the tool should let them save an incomplete package prior to "sending it" and then restart work on it)
  • to review an existing package as a receiver (show the list of existing ones for them to choose)
  • to review the summary of the reviews of the packages

When reviewing a package:

• user works through the structured data at resource element level, marking problems as they go (category - clinical disagrement | spec limitation | clarification needed + text comment)

When creating a package

• user can create sub groups within the package
• user can add content to the group. Each discrete addition is a resource
  • user picks an item to add
  • user fills out details of the content of the resource
  • resource is added to the group

User Login

• user should be able to login using their HL7 account (using HL7's light OAuth)
• other choices allowed but not necessary

Current Tool provider choice

Server: health intersections server. Will host a new one that specifically for this connectathon, with specially crafted content

Client: web application created by Relay Health

Technical Design Considerations

• each package is a [Composition]. each group is a section, and each resource is a subsection
• We would like to drive the connectathon tooling by profile. The workflow would look like this:
  • user identifies a [Profile] that they'd like to add to the package
  • tooling prepares a [Questionnaire] from the Profile (tool: Questionnaire Generator)
  • tooling generates a web form from the questionnaire and answers, if they already exist (tool: UI generator)
  • user fills out web form (with terminology support from server)
  • user submits form. Submitted content is validated, and then converted to a questionnaireAnswers resource (tool: web form handler)
  • web app stores questionnaire answers (if user wants to re-edit content)
  • tooling generates a resource form the questionnaire and adds to the composition (tool: resource generator)
  • when user marks the composition as complete, it's added to a [List] resource that tracks completed packages

Tooling

Questionnaire Generator:

• Candidate: the java reference implementation includes one
• pros for this candidate: it's in place, and any work on it can be leveraged by every one
• cons for this candidate: it needs some work yet
• Grahame's suggestion: we go with this, and I maintain it with advice from Lloyd

UI generator

• Candidate: There's an XSLT in the XML tools
• pros for this candidate: it exists
• cons for this candidate: it needs a lot of work indeed
• Grahame's suggestion: This is tightly tied to the client. Peter can choose to start from the xslt or not, but should take ownership of this. Producing something that contributes back would be good, but at Peter's discretion

web form handler

• Candidate: (none)
• Grahame's suggestion: tied to the UI generator - should be part of it

resource generator

• Candidate: none
• Grahame's suggestion: tied to the questionnaire generator. Grahame to maintain this

terminology server

• Candidate: Grahame's server
• pros for this candidate: it's done and read to go. Need to develop a good UI widget for a FHIR Tx server
• cons for this candidate:
• Grahame's suggestion: Stick with this. need to implement a few more code systems on it (list: CPT? ...?).