Profile Development Process for First Timers

From IHE Wiki
Revision as of 18:30, 9 March 2017 by Kevino (talk | contribs)
Jump to navigation Jump to search

This is how IHE Radiology works. Other domains will be similar but differ in some details.

  • We’re going to say “profile” a lot here but the process is essentially the same if your proposal was for a whitepaper, etc.
  • There’s lots of work to do before the first meeting
  • Good news: you can hit the ground running because your plan is in your proposal
  • Start working on the steps listed in your Breakdown of Tasks
  • Contact the people listed in your Support and Resources and listed as Contributors
  • Get them working on considering your Open Issues and proposing ideas
  • Start sketching the profile document
  • Use the template: Supplement Template V10.3
  • Practice Safe Pasting to avoid messing up your document (Paste text without formatting)
  • Lots of guidance in the template in <italic text>
  • Material from your Use Case section will get you started on Volume 1, X.4
  • Start working on an Actor/Transaction Diagram; it's a great highlevel view
  • If you want to work up some Swimlane Diagram screenshots, check out http://www.websequencediagrams.com - it's simple and tidy.
  • Three meetings (and optional tcons) will get the profile from Proposal to Trial Implementation status.
  • Kickoff Meeting (early-Novemberish)
  • Arrive with a skeleton profile document
  • Bring contentious/hard issues and be prepared to walk the committee through them
  • Make your best call for less contentious issues and write that into your skeleton.
  • It gives people something tangible to consider.
  • They can still disagree but if they agree you’ve saved time for more meaty discussions.
  • Committee will critique the contents and help you work through open issues
  • Leave with a complete idea of how you’re going to draft all the text for public comment
  • PC Prep Meeting (Januaryish)
  • Arrive with a draft Public Comment version of the document
  • Committee will review in detail and vote it ready for public comment if it meets the following criteria
  • All parts of the profile are written (not in stone, but the parts are all in place)
  • All questions where you want or need input/confirmation/consent from the wider community are listed in the Open Issues section
  • Issues that have been decided but you want to avoid rehashing with the email reviewers who didn’t hear the discussion are documented in Closed Issues
  • Reviewers are permitted to re-open closed issues but they had better introduce new facts/considerations beyond what’s documented in the closed issue.
  • Leave with a ready to publish for PC (possibly after some remaining tidy-up edits)
  • TI Prep Meeting (Late March/Early Aprilish)
  • Arrive with a draft Trial Implementation version of the document, a consolidated list of the received comments, completed resolutions for most comments, proposed resolutions for some comments, and
  • Committee reviews in detail and votes it ready for trial implementation
  • All open issues must be closed, one way or another.
  • Leave with a doc ready to publish for TI (possibly with some remaining tidy-up edits)
  • General Meeting Notes
  • You get allocated a number of time slots based on the estimated effort in your proposal
  • Most meetings spread your timeslots over a couple days so you can do homework overnight after the first day to work on issues/ideas raised
  • Ideally, post a draft document to the meeting folder a week in advance of the meeting
  • While it’s understood that some domain experts may not be able to attend for the entire duration of the face to face meetings, it is strongly recommended. It’s a way to learn by watching others while you're not in the hotseat. And frankly the point of IHE is for everyone to contribute to everyone else's work. We benefit from the breadth of view.
  • That being said, if you have travel constraints, or if you have contributors who will be joining the meeting by phone from another time zone, contact the co-chairs so they can take those constraints into account when scheduling the agenda.
  • Also, it’s expected that a profile editor may set up tcons with their contributors to work on the profile between face-to-face meetings


  • Where do things go?
  • If you're not on it yet, get on it now. This is where all the announcements, discussions, etc. go
  • Includes links to Agenda (times, places, logistics) and Minutes
  • Post documents here. Structure of meeting folders varies randomly each year


  • Reading/Reference List

Annex: Post-Kickoff Risk Assessment

At the end of the Kickoff Meeting, the Technical Committee assesses each workitem to make sure everyone is on the same page about the remaining potential risks and expectations.

The purpose is to get a clear picture of aspects the authors will need to focus on between now and the Public Comment Preparation meeting.

  • Run down the following checklist
    • Describe gaps in Use Case coverage
    • Describe unresolved technical issues/tasks
    • Describe potential practical issues
    • Does the open issue list feel complete
    • Which open issues feel most risky
    • How is the work fitting in the allocated bandwidth? (Time to spare? Just right? Things were left undone?)
    • How does the scope feel? (Room to expand? Just right? Pretty ambitious?)
    • If you had to reduce scope, what would you drop?
    • Have the promised resources manifested?
    • What tasks would benefit from additional expertise?
    • What vendors are engaged for each actor?
    • How many tcons would you like between now and the PC Prep Meeting?
  • Record checklist findings in the minutes

It will be the responsibility of the Profile Editor to lead resolution of risk items before the Public Comment preparation meeting.

Resolution may involve:

  • Scheduling additional Tcons to complete the technical discussion
  • Reducing the scope of the profile to fit within the allocated % bandwidth
  • Including open issues in the PC Profile draft for wider comment (generally for issues that would not radically change the profile)
  • Changing the workitem from a profile to a whitepaper to explore the solution space if it is not ready for profiling.
    • Hopefully the whitepaper work is solid enough that it will be ready to profile and the same proposal will be selected again next year
  • Dismissing the workitem as not ready for profiling in the forseeable future.
    • This likely means there was something the TC should have caught during evaluation

For sample evaluations see: Rad_Tech_Minutes_2016-11-01_to_2016-11-04


Annex: Post-PC Prep Assessment

Risks and Progress Template

Profile Name: <name>

Run down the following checklist and put it in your meeting minutes.

No risky open issues?

Did we get sufficient input on use cases

How is the work fitting in the allocated bandwidth? (Time to spare? Just right? Things were left undone?)

Did we line-by-line the entire document

Is it ready to go out for PC

How does the scope feel? (Room to expand? Just right? Pretty ambitious?) in terms of being a useful chunk of work

If you had to reduce scope, what would you drop?

Have the promised resources manifested?

What tasks would benefit from additional expertise?

What vendors are engaged for each actor?

When will we have sample data/objects

How many tcons would you like between now and the Trial Imp Meeting?

Where was the profile at at the start of the PC Mtg and would you have preferred to have more, if so what

Where was it at at the end of the meeting, are you comfortable with that, if not what more

Did you know what feedback you needed and did you get the answers you needed

For sample evaluations see: Rad_Tech_Minutes_2017-02-28_to_2017-03-03

Retrieved from "http://wiki.ihe.net/index.php?title=Profile_Development_Process_for_First_Timers&oldid=100685"