Health Ingenuity Exchange ( HingX ) Best Practices for User Groups and Resource Registration

1. Health Ingenuity Exchange (HingX)Best Practicesfor User Groups andResource Registration

2. HingX Project Overview • HingX – Health Ingenuity Exchange – a registry and repository for Health related Information and Technology Resources • Initially sponsored by the Rockefeller Foundation to enable an enterprise architecture approach to e-health for low resource countries they are also sponsoring • Projects also being sponsored by Rockefeller are first trial users • HL7 has committed to be an early adopter • Three software versions have been released with approximately 1 release per month anticipated

3. Relationship between HingX and Repositories HingXREGISTRY Third-Party Resource Repository Third-Party Resource Repository HingX Reference Resource Repository Third-Party Resource Repository

4. What is a Resource? • A Resource is general concept for any type of digital file that may be used in some aspect of a Health oriented information and communication technology system • Specific types of resources can be: • Documents in any format • Diagrams as images or editable representations • Images as editable or only viewable • Other formats intended for human viewing • Software components • Control files • Meta-data • Other formats intended for computation

5. What is a HingX User Group? • A HingX User Group is a registered group that can contain many Users in different Roles • User Groups can be thought of as Communities, Organizations, Projects or Teams • Resources are managed via User Groups • A User Group is the designated “govenor” of a Resource. • Resource access and security can be restricted to a single User Group or can include other designated User Groups • All Users in a User Group share the same access to Resources based on security settings for a Resource • User Groups are not nested but the same effect can be obtained by distributing Users into related User Groups

6. What is a User? • A User is associated with a single individual’s identity, including name and e-mail coordinates. • A User is associated with a primary User Group, usually one from which an individual receives delegated authority to act. • A single user can participate in more than one User Group • Each User can be assigned one or more Roles in each User Group, depending on what actions can be taken regarding Resources associated with the User Group.

7. What is a Role • A Role is created to designate the set of actions that a User can perform regarding the Resources related to a specific User Group • HingX has a standard set of Roles • The types of actions include: • Search, Filter and Browse HingX Registry • May “Like” and “Follow” Resources • Contribute to Resource Discussions • Manage Resource meta-data descriptions • Moderate a Resource’s Discussions • Manage a Resource Security and status

8. What are the typical Role Types? • General Public – non-registered users • Consumer – may consume authorized resources • Contributor – contributes resources and changes state • Curator – can describe resources • User Group Administrator – can add users to user groups and assign roles

11. User Group Design Principles • A person can have more than one role in a User Group • More than one person can play the same Role in a User Group ROLE (Permitted Actions) USER (Identity of a Person) • A person can participate in many User Groups with different Roles in different User Groups USER GROUP (Group of Users) • Access to a Resource is through a User Group • A Resource is “governed” by a single User Group Resource (Physical Instances) • Restricted Resources can be made available to Users in more than one User Group • An Resource Folder is a registry record that identifies more than one Resource Resource Folder

12. Configuring User Groups • Configuring a set of User Groups requires understanding the relationships between User Groups and their requirements for managing resources • A Resource life cycle and a corresponding approval process should be established in advance • User Groups must be configured to maintain authority over Resources across their life cycles

13. Resource Life Cycles • A resource instance is governed by a single user group. • A resource instance may have a status of “under development”, “under review”, “active” or “inactive”. • A new version of a resource replaces the current version. The status of the old resource becomes inactive and the new resource becomes active. The relationship between the two resources is that the new one replaces the old one. • Other relationships can exist between resources.

14. User Group Types • Community – a group of people, who may be from different organizations, working together to achieve a shared purpose they could not achieve working independently • Organization – a group of people with formal responsibilities for specific processes and their corresponding resources • Project – a group of people with assigned responsibilities working together to produce specific resources that may be interdependent • Team or sub-project – a group of people with specific skills and assigned responsibilities for specific resources over time

15. Possible User Group Configurations Organizations Projects Communities Teams

16. Some User Group Scenarios • A specific organization may create a set of User Groups to manage processes and their corresponding Resources - the emphasis is on the scope of authority of each group • A project is initiated to develop a new set of resources or to maintain, enhance or extend an existing set of Resources • A set of teams is formed within a Project to be accountable for different, but interdependent resources • A group of Organizations decides to form a Community to work together to achieve a common purpose. The Community may create multiple Projects with multiple Teams to achieve the stated purpose. • A number of Teams may be created by a Community, a Project or an Organization to manage the distribution of accountability for specific Resources • A large scale Project is initiated that may require multiple project teams to manage accountability to develop and enhance interdependent resources

17. Scenario 1 – single organization • A single organization internally manages the contribution of all resources it produces • No resources are contributed unless they are ready to be used • Only one User Group exists for the Organization • The resource life cycle is: • Active – Ready to be used • Inactive – Obsolete and should not be used – may have a replacement resource

18. Scenario 2 – One Organization and Several Projects • A single Organization initiates one or more Projects to produce Resources • The Resources are interdependent so members of each project must accept the resources produced by other projects • The Resource Life Cycle is • Under Development – Resource is changing rapidly • Under Review – Resource is being examined/tested • Active – Resource may be used by others beyond the organization • Inactive – Resource is obsolete and shouldn’t be used any longer – a replacement Resource may be available

19. Scenario 3 - Community • A number of organizations agree to form a community to achieve a shared purpose • Each organization is a User Group and delegates people to represent them in the community • Resources may be the responsibility of the community as a whole or by participating organizations, more focused communities or projects • The community initiates projects to acquire/produce resources that contribute to achieving the shared purpose • Projects have teams drawn from different organizations to manage resources across the resource life cycle • The resource life cycle is: • Under Development – Resource is changing rapidly • Under Review – Resource is being examined/tested • Active – Resource may be used by others • Inactive – Resource is obsolete and shouldn’t be used any longer – a replacement Resource may be offered instead. • Community members are assigned to Project Teams that have responsibility to produce/change resources • Community members may be members of Review Teams to review and validate that Resources are fit for the intended community purpose

20. Case Study – DECOR Community • DCORE community has multiple projects contributing resources. • The resources contributed may be templates, value sets and concept definitions for use by related projects. • Projects develop and reuse resources to achieve their shared purpose • Different organizations may be involved to produce and approve resources. • Perinatology Project is an example

21. Perinatology Project Testing Team Specification Development Community Interface Development Community Requirements Community Gyns Software Developer Team 1 Architects Terminologists Midwives Software Developer Team 2 HL7 Standards Experts