SIGN IN AT http://bit.ly\HL7PC0518
|Mon Q1||Saal 1, Maritim||Plenary||Not Applicable|
|Mon Q2||Salon 4, Eifel||20||Admin||PC||Jay/Emma||N/A|
|Mon Q3||Saal 2, Heumarkt||Mega Report Out||EHR||Not Applicable|
|Mon Q3||Salon 4, Eifel||20|
Device Ballot Reconciliation
|Mon Q4||Saal 14, Köln||Workflow||FHIR-I||Not Applicable|
|Tues Q1||Saal 2, Heumarkt||40|
Status of skin & wound terminologies
Accepted: LHS, CIMI, EC
|Tues Q2||Salon 16, Königswinter||20|
Clinical Notes in FHIR (continuation from Jan 2018)
|Tues Q3||Saal 2, Heumarkt||20|
FHIR Admin + FHIR Trackers
|Tues Q3||Salon 16, Königswinter|| HAI (FHIR and CDA) ballot reconciliation (Sarah)||SD||Not Applicable |
|Tues Q4||Saal 2, Heumarkt||40||Negation + AllergyIntolerance value set + Clinical Status Value Set||PC||Jay/Emma|
Accepted: Vocab, Pharm, CIMI, SD, OO, CG
|Wed Q1||Salon 15, Bonn||20|
FHIR Trackers (Procedure)
|Wed Q2||Salon 20, Fulda||Joint with PA||PA||Not Applicable |
|Wed Lunch||Bistro La Galerie||Clinicians on FHIR update / plan for next WGM||Russ||N/A|
|Wed Q3||Salon 19, Würzburg|
OO resources of interest to other workgroups
|OO||Not Applicable |
Invited: CDS, Pharm, PA, CQI, FHIR-I
|Wed Q3||Saal 1 Maritim (table assigned)||Common Clinical Registry Framework||CIC||Not Applicable|
|Wed Q4||Saal 2, Heumarkt||20|
|Thurs Q1||Saal 2, Heumarkt||35|
CarePlan report out
Accepted: Pharm, LHS, SD
|Thurs Q1||Salon 19, Würzburg||Common Topics||OO||Not Applicable|
Invited: CDS, Templates
|Thurs Q2||Saal 2, Heumarkt||25|
Template update (Template co-chair/rep)
*Topic CDA Templates as StructureDefinitions
Accepted: Templates, SD
|Thurs Lunch||Saal 2, Heumarkt||10||Co-Chair Admin (plan next WGM agenda and PSS for Bidirectional Services eReferrals)||PC||Michelle/Michelle||N/A|
|Thurs Q3||Saal 14, Köln||Clinical Statement||CS||Not Applicable|
|Thurs Q3||Saal 2, Heumarkt||20|
FHIR Trackers (AdverseEvent)
Please add a 10-15 minute discussion re: the
Women’s Health Technology Coordinated Registry Network (CRN) -
|Thurs Q4||Saal 14, Köln||CareTeam DAM||LHS||Not Applicable |
Monday Q2 Admin Notes
1. Sign in sheet - Jay will set up the attendee list in google doc
2. Agenda review
- Q3 Mega Report out - PC Slides - Last update by Michael Padula. Michelle will update FHIR slide and send to Laura
- Q3 - Device recon - Jay chairing/scribing
- Q1 CIMI agenda -
- Clinical groups asking for updates from CIMI?
- Jay will follow-up with Susan.
- Update on Wounds - Jay will follow-up with susan
- Q2 - Clinical Notes
- Q3 - CCDA score card - emma covering
- Q4 - Allergy substance need a vote. Clinical status - nesting for FHIR valueSet, SNOMED does not nest - hierarchy. FHIR I is attending to clarify.
- Q1 CIMI agenda -
- Q1 - FHIR trackers (Procedure)
- Q2 - PA agenda - need to request to add to their agenda - V2 change to chapter 3 (owned by PA) that effects chpt 11 (owned by PC). the change works for chapter 3 but does not work for chapter 11. Was sent to ballot for public comment. now have public comment. Amit need time to speak with publishing about it - after today Q3. Amit will discuss it at the meeting
- Lunch - CoF -
- David Hay will demo ConMan.
- Discussion about the use case and the process we will follow.
- Discuss clinical expertise at technical connecthathon.
- Room will be preferable
- Q3 -
- Biologically Derived product - Jay/Michelle.
- Common Clinical Registry framework - meeting at a table in Saal 1 Maritim
- Q4 - fhir tracker
- Q1 - Care Plan Report out. Laura will pull the list forward
- Q1 - Common topics with OO
- Q2 - Template update. Clinical status continue (Lisa attending to discuss)
- Lunch - PC Admin
- Q3 - BR&R; trackers; CRN PSS will need to be voted on. PC wants to sign on as co-sponsor. However, if concerns, will be expressed by the both BR&R and PC. CIC is concerned that CCRF is not used. Laura will be involved (as PC rep) in ensuring the HL7 process and timeline is followed. Jay: motion for PC to co-sponsor; Laura second; further discussion: motion is conditional for co-sponsorship based on the following reasons: 1) dates need to be corrected to be support plan to become normative (as per process) - can a profile be normative if the base resources are still in flux? 2) Need implementers if going normative 3)primary sponsor to be CIC 4) need to conform to CCRF. Vote: 0 oppose; 0 abstain; 7 for
- Further discussion will happen if folks attend on Thursday
- Q4 - LHS Care team - continue plans for the DAM
Monday Q3 Device IG
Monday Q4 FHIR I Workflow
- Workflow overview
Definition pattern - actions that can occur
Request - planned, ordered, recommended (properties typically attributes that are generic)
Event - happening right now or have occurred.
Request patterns: FHIR I have reviewed the patterns and asked workgroups to validate if discrepancy are intentional. How in FHIR do you get something done. Simply having some way to get things done.
- Identified a number of places to do those things and provide guidance when to take this approach.
Third piece - created new resource - exampleScenario: makes visible to implementers workflow that have been defined (using plandefinition and activityDefinition).
Request pattern has an element "requestIntent" - implementers track orders in 2 ways
- the ones they have control over
- orders that come from another system they don't have to track
The business rules are different between the two. When the orders you execute - will capture more details. When from other system, capture what you get from the patient.
should there be an element for "external" requestIntent?
Jose - Overview of workflow exampleScenario. Instantiation of plandefinition
- formally define what your workflow process is using planDefinition
- Describe how your workflow works
- or use both
Toolkit is publicly available. Can point to the tool from the workflow page.
Tracker Items Discussed -
15782 - Update definitions for codes in valueset-request-status
Tuesday Q1 PC with CIMI
- the CIMI model persisted in BMM is the CIMI model - if the archetypes fail, then it is not a CIMI model - this determines the CIMI reference model.
- CIMI keep evolving - the tools do not matter as long as the archetypes generated are consistent with the top level of CIMI - in terms of which tools are used doesn't matter as long as the result is compliant with the ADL
- The model will evolve over time. There will be snapshots over time saying this is the CIMI model version X., can still demonstrate conformance to this current model.
Status of skin & wound terminologies
- update by Susan Matney
- the wound model vocabulary is ready. The formalism has many ballot comments and still being worked on.
- All content for value sets has been developed in the SOLOR extension namespace.
- Next step is to get the CIMI models in CIMI
- this will be done after after the push for labs
- Need to have it formalized in CIMI first - develop the archetypes, the value sets defined.
- Then talk with FHIR and with PC to discuss translation into FHIR.
- Anticipate invites to PC to a CIMI call to discuss the formalism, BMM, etc of the wound assessment. will review the structure and the syntax, the inheritance from the CIMI model.
- need to talk to PC about the FHIR development process for assessment.
- there are 2 groups wanting to implement the FHIR profiles - podiatry, and the mobile app - Tissue Analytics.
- the value sets are also loaded in VSAC - except for the extension concepts.
CIMI current state model for adverse event
- Claude provided update of work/diagrams in adverse event
- began with formal requirements and use cases from Russ L and Stephen Chu and Elaine Ayers
- Russ update - Adverse Event needs more definition on its requirements and workflow.
- Claude showed requirements tool with Adverse event requirements and the Magic draw tool showing the information model for adverse event.
- Lots of discussion re: relationship between allergy/intolerance/adverse reaction.
- Patient Care needs to take the Allergy/Intolerance DAM and do a 2nd ballot ASAP to include the Adverse Event details.
- . Future discussion re: the relationship of CIMI and HL7 WGs on DAM development is there s requirement for a DAM for CIMI models? Best practice would have the models reflect the reality - need to have conversations of the role of DAMs, the need for balloted DAMs, the review process for DAMs etc. What is needed? This speaks to HSPC and especially to CIIC - in the end we want clinical experts to verify the structure relates to reality.
CIMI content onboarding process
- deferred to another undetermined future meeting.
CIMI publication status & implementable derivations
- deferred to another undetermined future meeting.
Tuesday Q2 - Clinical Notes in FHIR (continuation from Jan 2018)
* Update on the Connectathon
* Update from Argonaut
Notes in FHIR
- New notes resource
Proceeded with documentReference
- Argonaut priority – Clinical notes
- Common clinical notes – these are the base line.
- This is like having an index -
- Searching is easy – what you get back may not be as easy to be able to read but at least you get something back.
Documentreference.class – category for the note – see tracker 17171
- Most implementations have classCode and typeCode as the same code
- Change class to category (will assist with not getting all documents back)
- Suggest preferred binding
- Change class cardinality to 0..*
Need to query and get clinical notes back. If LOINC will define
Suggest a separate list of category and type with the differences between the two. Lots of ambiguity about this. Need to set a minimal bar.
Diagnostic report – parking lot it for now. Need discussion about if it should be included in the list of “clinical notes”.
Point made that DocumentReference can point to anything.
Common Clinical notes Set
Discharge documentation – has one code for discharge document and another for hospital course. Use the most generic code as default.
Progress note – use provider-unspecified progress note as default
Open issue – (MIME type and LOINC codes) how do you know what the server support?
- Client need to know what the server supports for both write and read - Some server supports write in one format but does not support read in the same format.
- Suggested solution: have an $expand valueset
- Noted the Fhir spec discourages different outbound and inbound
- Discussion about the Context of the $expand valueset operation
- Explore this more with fhir-I
- Need to be a broad solution – this is a FHIR I problem.
Patient Care Questions
- Continue design and testing with documentReference? Yes
- Interest in participating in sept Connecthathon? yes
Continue this session next WGM. Will need this until USCDI is figured out.
Plan is to use this in US Core
Is this work worthy enough to go into FHIR core? see Tracker 14720 - see tracker 14720
PC will draft some verbiage. SD will vote on it.
Tuesday Q3 - FHIR Trackers
Chair / Scribe: Michelle Miller
- GF#16678 Recommend that NDKA be a requried field as it is reportable to the patient record as a required value - 2018-May Core
- GF#15781 AllergyIntolerance.assertedDate
- GF#14643 Asserted Date on Conditon and on Condition Definition page have inconsistent definitions
- GF#16062 Clarification of PerformedRange in Procedure resource 2018-May Core
- GF#15809 Procedures cannot be searched by "reason" or "reasonCode"
- GF#15682 Add attribute to enter body site laterality in Procedure resource - discussed, but not resolved due to lack of time at the end of quarter
Tuesday Q4 - Negation/AllergyIntolerance Value set/Clinical Status
C-CDA document to FHIR document transformation.
- NegationIND = true + Family history of cancer transforms in FHIR as a positive assertion.
- FHIR observation, ignores the assertion and put in the Boolean to represent the negated thing.
- Observation – guidance section – should not use the exertion pattern. This is a ‘Should” not a SHALL. It’s not good to have assertion code because it’s useless for searching. There is not a single bound SHALL that everybody will follow. The recommendation is if you have a choice to not use the assertion.
- What should the pattern be in situations like this? Per Grahame, putting the finding code in the observation code.
- CDA never made the split between Act negation and value negation.
- Could define multiplying extensions.
- Another option is to use the code for what you want
- FHIR is using situation with negated concepts
- Use of negation is a good topic to explore by CDA management group for alignment.
- At some point Not done was inflated to mean not heave.
- Solution may introduce ambiguity.
AllergyIntolerance value set
Published results in VSAC
1 of 5 negatives withdrawn; outreach in process
Would like to maintain this valueset. Invite allergy contributions next maintenance round.
Motion: Emma moved to publish the allergy substance valueset pending
Second Rob Hausaum. No further discussion.
Vote: 1 oppose; 6 abstain; 22 for
Clinical Status Value Set for C-CDA problems
Clinical status / Problem status
- CCDA 1.1 Problem status observation (active, inactive, resolved; SCT)
- CCDA 2.0 Deprecated
- CCDA 2.1 still deprecated
- STU comment 1357: still needed; undeprecate. Accepted & in Errata
- (you do have to know where to look)
- We want CCDA and FHIR to have the same values, right?
- FHIR list
i. apply ‘controlled’ value changes
ii. Is “code” datatype appropriate for a clinical element?
i. Semantic only (same terms & implicit semantics, possibly with a map)
ii. Or lexical (same codes, system)
- Which one
- Document requirements so we can prevent flare-ups.
Problem status template (and allergy status template) got un-deprecated. Currently both problem status and allergy status uses the problem status value set. The concepts being discussed are for problem status.
- CIMI has different values
- CDA management group can use this as a proposal to for the process to take to align valuesets
- The concepts terms are semantically not the same – some are nouns and others are adjectives.
- Datatype is CD so the binding is built into fhir.
- FHIR use of Code, codeable concepts, SNOMED, FHIR defined codes
- This is a valueset is clinical so use of Code is not the appropriate.
- Suggestion for FHIR to make this a Codeable concept where the values are required but can still be a required binding.
- If ballot to be normative, can add additional codes to the valueset that has meaning that is not already in the valueset.
- Discussion as to why FHIR is not binding to SNOMED.
- Possible to publish the SNOMED mappings for informative reasons.
- SNOMED INT’L – it’s possible to include the SNOMED set but will it be used?
- Suggestion to do concept maps.
- Some organizations want to use SNOMED and LOINC directly and not have to map to some other codes.
Motion: Emma Moved for the Clinical Status concepts used for fhir condition.clinicalStatus to be used for C-CDA problem status.
Amendment (By Gay): CDA management group Agree to conceptually align the clinical status concepts as best as possible, working with Patient Care and SDWG
Vote: 0 oppose; 3 abstained; 28 for
Will need a collaboration work space (wiki page, confluence) to document requirements.
Wed Q1 FHIR Trackers
Chair / Scribe: Michelle Miller
- GF#15682 Add attribute to enter body site laterality in Procedure resource
- GF#15691 Add an element to Procedure to indicate whether an individual chose to self-direct the service - discussed, but not resolved because we wanted to sync with OO
IsModifier (all resources)
- GF#15583 PC Missing IsModifierReason - briefly discussed, but no vote because Russ joined us and we wanted to switch focus to CareTeam
- GF#14334 allow careteam.participant member to reference a Practitioner role
Wed Q4 - FHIR Trackers
Chair / Scribe: Michelle Miller
- GF#15583 PC Missing IsModifierReason
- GF#15579 why is carepplan.activity.status an is_mod?
- GF#15644 review Careplan "completed" status
- GF#14483 Use of reference for planDefinition in carePlan need to be added back. 2018-Jan Core-InPerson
- GF#14959 Clarify difference between Requester and Sender in CommunicationRequest
- Care Plan –
- HL7 CDA R2 Personal Advanced Care Plan Document - Lisa Nelson
- CDA 2.1
- Collaborative Review of CDA Management Group Pilot Template Review.
- IHE QRPH Early Hearing Detection and Intervention (EHDI) Plan of Care- Lisa Nelson
- Pharmacy Templates CDA IG
- Nutrition Care Plan
- IHE PCC
- Dynamic Care Planning Profile- EJ
- Update: PlanDefinition/ActivityDefinition
- Care Team Managment Profile – EJ
- New: CDA - Care Plan Summary Section – EJ
- Work is published
- Struggling with how do you know the systems ability to consume information. Struggling with information blocking. If CDA document can be read. Concern with processing.
- Mu2015 required systems to demonstrate capability to consume CDA content.
- Relevant and Pertinent need consideration
- USCDI – big gap for Care Team from CCDS, Care Plan is a gap. Data provenance is coming at us. Suggestion for this group to focus on certain core data elements. Also need to address USCDI in the Care Plan DAM. Provenance is being discussed a lot at Cerner lately.
- Provenance – suggestion to expose this at HL7. Suggestion to share at the implementation-a-thon project since ONC is at that table.
- USCDI – Care Plan, Care Team, Provenance are at the top of the list. Provenance comments not published. Anything folks can put together very quickly will be really helpful. Need to align this with anything that can help. Need to start looking at standards that already exists. Vendors need to provide input into what they currently do. “Best shot at what this can be that most people will do is this …”. Need this before June 4th. What do we need to do:
- Responses were “what do you mean by this?” should have been “you should mean this by that …”
- Implementation-na-thon in June will take this up as a topic.
- Could provide guidance
- Cerner provider response related to FHIR use of the W2.
- Suggestion to schedule a few calls over the next couple weeks
- Confluence page – CDA management group will start the process. will including ONC contacts.
- Not being advanced forward. Considering if need to take off the list.
- Concerns: Pharmacy WG put out pharmacy templates. SDWG was not aware. Pharmacy extensions were created for everything regardless that it is represented in CDA. Suggestion to create mapping table. No sample files published with it.
- Values sets review and check over going out on the list serv. Will be published soon.
- Tested at FHIR Connecthathon
- Updated IHE profile going out for public comment in the near future
- Consider updating for IHE next proposal year.
- Part of IHE CDA-DSS (Document Summary Section) Profile
- Overview provided
- Workflow - Need clinical base guidance – don’t put the IT solution ahead of the practice. Need clinical care to drive this.
- How can we drive this change? Suggestion to model the provider behavior.
- Suggest doing something similar or the Electronic reporting responsibility response – requirements for the receive and sender
- SDWG is doing things that does not go into workflow. This is something that needs contribution to. The requirements need to be informed by deeper understanding of workflows. This is leading to disparate outcomes. Brent James teaching that everything that humans do can be drummed down to a few things. Need the practice community and the technical community to attempt to do this.
- This can be considered for CarePlan 2.
Template update (Template co-chair/rep)
Structured Doc/CDA update (SDWG co-chairs)
Added a few attributes to the clinical statement
At the end of the standard is a spreadsheet like the HMD that highlights all the attributes that have been changed
Extensions were added it they were added to the SDWG CDA 2.0 extension page - http://wiki.hl7.org/index.php?title=CDA_R2_Extensions
Suggestion that Pharmacy classes should have been added. Should start a new extension page for 2.1
There are two schemas that are published. The new scheme to accommodate the new attributes.
ActParticipation type code was widened to include all the RIM actRelationship typecodes.
At the very end of the ballot. An informative component. Makes it easier to see what was in it.
Was there addition of relationship between classes? No new relationships were drawn.
RIM harmonization version number changed from numeric to a string – had to reach into 1B for that change
Ballot status: closed all the negative. 2-3 months to get to publication
Allergy/Intolerance harmonization; Clinical Status Value-set
CDA Management group working on evolution process. Want to go back and look at templates that keep coming up as issues.
CDA MG will help identify gaps – value sets; guidance on transforms between CDA and FHIR; general clarity on data elements as an industry regardless of technologies. Goal is to start with problems and allergies.
New allergy intolerance value set – how it plugs in
Status (problem concern, problem status) same as allergy. Reaching out to PC, Pharm for medications. If PC supports this CDA management group and come back to patient to PC with PSS for co-sponsoring.
Mapping project happening between C-CDA and FHIR (Templates as StructureDefinitions)
Structure Definition – constraints on base model. Now have a CDA logical model where Grahame as expressed the R-MIM in FHIR CDA structure definition. This provides the ability to profile and describe how to constrain both CDA and FHIR. Will be nice for CDA template tool to reverse the process.
Initial prototyping has been done on this. Rick and Shawn working on this. Some gaps have been closed. There is still conceptual differences.
Have talked about this but have never realized a PSS to get this work done. Have to go to the CTO if this is for tooling – he has a tooling budget. It may not be about funding, but it is about money because two groups of tool smiths involved.
PSS need to capture
- publishing CDA
- FHIR tooling; validation
- Searching for things
- Property control
Can do PSS at any time unless heading for a standard then have to follow the dates.
SDWG took responsibility for the mapping because to the structure. However, the ownership of the vast majority of the templates are owned by Patient Care. As part of the CDA management group work is looking at following the fhir model and have work groups take ownership. Opportunity to take a more strategic approach. Patient care, Pharmacy, Financial management are the three groups to do a pilot with. CDA entry templates mapped to the FHIR resource with the associated work groups.
What plans does PC have ramping up to take control of this work? This is the first time PC is hearing about this.
CDA is intended to be a document you can read but has morphed into something different.
C-CDA is based on clinical care with the use of codes. Will need clinical expertise, terminology expertise.
What happens now? Does patient care get the ownerschip of C-CDA templates? What happens with the international aspect?
- IHE does international
- HL7 is also international – why are they only focusing on US?
Work load will follow where it goes because of the domain expertise.
Is there a way to separate less tight coupling? The problem is binding vocabulary imposes the structure.
What is the task of HL7 international? To produce international standard. If in workgroups, whose job is to do the work. IPS – SDWG is the sponsor but not the owner. CDA management group question.
C-CDA on FHIR updates
- STU balloted in Jan 2017, wrapped up in Dec 2017. Has been published. Broken links in the headers. Implementations using it already (care Plans)
- No XDS-SD (FHIR has documentReference that can be used).
- Current version have sections and entries that are in C-CDA – logical equivalent for US Core work. Sections for content where no US core exists points to the base resource.
- Committed to making updates so there will be a new version
- Mapping project ongoing – owned by SDWG
Thurs Lunch - Co-chair Admin
Attendance: Lisa Nelson, Emma, Laura, Jay, Michelle, Abdul
PSS for Bidirectional Services eReferrals - Jay/Emma: 5-approve / 0 - against / 0 abstain
Review agenda for Sept 2018 WGM - Patient Care Agenda and Minutes
Lisa Nelson noted pilot project where CDA management group suggested domain groups have more control over the templates (both structure and value sets). Pilot started with PC - problems/allergies, FM - payer/coverage/policy activity, Pharm - medication activity, CQI - overlapping templates with QRDA and PC. Lisa took list of CDA entry templates and used existing maps from US Core and CCDA on FHIR to see which resources map to each entry templates. Patient Care has A LOT of templates whereas other work groups only had a couple templates.
Thurs Q3 - BRR/PC
Chair / Scribe: Michelle Miller
Recap last WGM.
There may be differences between clinical research and allergies/clinical use case. In clinical research, the first occurrence is considered an incident or adverse event, but the first occurrence of an allergy reaction is not considered an adverse workflow.
Is the AdverseEvent the adverse workflow or the adverse manifestation? AdverseEvent is when something undesirable happens and then track anything that may help determine causality.
Regulatory use cases:
- Associate drug to AdverseEvent
- Which stage of medication process? AdverseEvent.category is 0..* because there can be multiple axes of categorization, so you could use category for "when" it was caught: ordering vs dispensing vs administrating the medication.
- To pinpoint the root cause was a barcode, a change request is recommended.
- Other root causes, which can vary by category
- Barcode or NDC issue
- Communication (illegible handwriting, unclear verbal message)
- Container labels or carton labeling confusing
- Container labels or carton labeling look alike
- Data entry error
- Device malfunction
- Human factors (e.g., knowledge deficit, product name was abbreviated on the computer listing)
- Instructions for use are confusing
- Name confusion (drug names look alike or sound alike)
- Other (text/speech to text field)
- Packaging (product for oral use was packaged in a vial typically used for injections)
- Prescribing Information is confusing or inaccurate
- Product quality issue
- Products stored next to each other
- Wrong storage temperature
- Fetus has AdverseEvent when med was administered to parent/mother
- Link fetus infant report to parent report if parent also experience the adverse event
- Is this referencing another DocumentReference (the resource allows that) or referencing an AdverseEvent or some kind of a knowledge artifact saying they are linked together (Linkage allows you to link two AdverseEvent resources)?
- Product, problem, or med error without a patient - medication didn't reach the patient
- Incorrect instructions on a medication dispense, but the patient caught it before taking the medication. The subject is still the Patient, but the AdverseEvent.actuality = potential.
- Possible change request: Do we need to document an expected vs unexpected AdverseEvent?
- For example, an expected AdverseEvent might be giving non-compatible blood in an emergent situation when compatible blood is not immediately available.
- A defective bottle of medications (or stinky tray of food) where a specific patient is not identified yet. Is this the Group of all patients (at risk) OR relax cardinality of subject to be optional OR is that not within scope of AdverseEvent?
Resolved GF#16027 Add date when AdverseEvent detected
To log new change requests: Click "Submit a Change" on the bottom of FHIR specification, which opens gForge. To get a gForge account, refer to http://wiki.hl7.org/index.php?title=FHIR_gForge_Tracker#Who_can_submit.3F