Short term tasks
MIF freezing
1. Figure out which part(s) of the MIF we can reasonably declare stable. Some parts such
as templates are just placeholders and cannot be considered stable at this point. Other
parts, such as the dynamic model, are still subject to intensive debate, and would be risky
to consider 'stable'.
My recommendation: The list of 'stable' portions should be: Static models (flat and
serialized), datatypes and (if possible) vocabulary. This will include the 'common'
portions such as header information, annotations, markup, history and derivation.
2. Perform intensive review of those portions designated "ready for stabilization", perform
alignment with UML, and declare them final
Target date for freezing: June 30
Maintenance process
1. We need to define the process under which changes to 'frozen' portions of the MIF will
be accepted. The objective of the review process is to ensure no changes for at least the
next 18 months. However, a long term process for maintenance and approval of changes
needs to exist
My recommendation: The process should include a means of proposing changes and an
approval process. The approval process should include input by MnM,
Publications, Implementors and Tool-smiths. Each change should be
accompanied by a list of impacts, and a plan and timeline for rolling out the
change.
Target for initial process approval: June 30
Short-term MIF
1. With those parts of the MIF that have been designated as "stable", construct a "MIF
subset" that represents the capabilities of existing tooling and repositories.
2. Document what changes will need to be made to existing tools and repositories to support
this 'initial' subset. (It is likely that some elements that are 'required' by the MIF or which
are represented or handled differently will need to be added to the tools.)
3. Modify tools to be able to import and export MIF functionality
Target for tool development: August 30
Tooling Requirements and Architecture
1. Document the 'capabilities' that HL7 users will need to have in the short to intermediate
term.
My recommendation: Things I'd like to see included:

Support for full MIF within existing tools, including publications

Ability to generate a Visio diagram from MIF information

Ability to view a 'parent' model along side it's children to see derivation
restrictions

Ability to view a 'new' model along side it's original to view changes

Ability to display a MIF document
2. Determine the tooling environment(s) to be supported
3. Define an approach for an object model that can be shared amongst multiple tools,
preferably across all environments
My recommendation:

If possible, a model that works in both Java and COM.
4. Define the set of 'component' behaviors that would be useful to have.
My recommendation:

Sharable internal capabilities
i. Basic object model operations (construct, add items, remove items, update
items)
ii. Import model from MIF XML into object model
iii. Export model from object model into MIF XML
iv. Import model from database repository into object model
v. Export model from object model into database repository
vi. Import model from ebXML repository into object model
vii. Export model from object model into ebXML repository
viii. Convert MIF XML to XMI
ix. Convert XMI to MIF (raising errors on non-MIF-compliant XMI)
x. Perform internal validation on a model. (Only looking at the data within
the model)
xi. Perform external validation of a model against a repository (checking
external references)
xii. Given a source and target model, fill in the 'derivation' information
indicating whether one is a proper restriction/extension/etc. of the other
xiii. Given a source and target model, identify the changes between the two
models.
xiv. Given a model and a set of changes, apply those changes to the model.
(Should be capable of ignoring changes that are not relevant to the model.)
This would be used to propagate model changes
xv. Transform a flat static object model representation to serial representation
and vice-versa

Sharable interface capabilities
i. Allow display of marked-up text (simple or complex)
ii. Allow editing of marked-up text (simple or complex)
iii. Allow display and navigation of vocabulary (for a specified domain)
iv. Allow display of annotations
v. Allow editing of annotations
5. Identify which existing and proposed applications would make use of which components
6. Prioritize component development
7. Develop detailed requirements for each component
8. Determine development language for each component
My recommendation: Java for internal components, VB for external components
Target for component prioritization and requirements: August 30