Architecture Implications of Strategic Initiatives
The ArB has been asked to review the current Strategic Initiatives http://www.hl7.org/documentcenter/public_temp_4317B327-1C23-BA17-0C1A0B3243A75B52/strategic/roadmap/HL7_2012_Strategic_Initiatives%20FINAL.pdf and provide feedback to the TSC. In addition, this we agreed to review them for implications for the HL7 Business Architecture.
- Leadership in the Global health standards communities is acknowledged to take effort - 2.1
- No clear how these Board level activities relate to TSC and below activities - the Business Architecture should at least have communication channels from these included since they appear to impact TSC and below processes
- It is clear that the Board wishes to be able to pursue and measure progress toward increased efficiency of internal processes to be able to be responsive to new requirements for standards development, enhancement, alignment of new standards. (2.2)
- This has implications for the Business Architecture to identify how requests come into the organization, projects initiated and prioritized so that resources can be assigned/recruited to achieve the results required.
- The expectation that quality metric definitions such as "fit for purpose" need to be included in project initiation processes.
- The ability to measure consistency across standards families and actual reuse is also needed.
- A requirement for an enabling technical infrastructure for V3/CDA/Templates that enables traceability, minimizes manual effort, is accessible to both within the formal HL7 Community and beyond to direct and indirect consumers of HL7 Standards, and supports rapid "customization" while maximizing consistency and reuse is recognized. 2.2.4
- The ability to take advantage of such an infrastructure will require corresponding governance, management and methodology to measure consistency, reuse and general interdependent artifact change management.
- Numerous Board level governance issues exist in terms of protecting IP, cost of developing and maintaining such an infrastructure, return on investment measures, development/acquisition criteria, etc. are inherent in such a technical infrastructure. Some recognition of this is acknowledged with the strategic initiative of developing a tooling strategy - some work is underway. Since the Arb scope is TSC down, it is not clear whether these governance issues are included or not - but at least the channels for those decisions needs to be included - implications up - direction down.
- Managing such an infrastructure needs to be included in the Business Architecture, whether it is the sole responsibility of HL7 or is done in collaboration with other standards organizations or industry consortia such as Open Health Tools
- I think the infrastructure issue is inherent in any of the product lines so should not just apply to V3ish specifications
- Ease of use strategies in 2.3 needs some of the output of the 2.1.5 to help identify what are the different customer groups who's needs are measured as well as some measure of standards uptake by product line
- Product definitions were identified in previous work - see Standards tab off the main HL7 web page, but not actual "product lines". Not clear the degree of granularity anticipated for product lines, nor whether there is expected to be alignment between them. Many environments are now working with combination of HL7 standards (V2 carrying CDA) and even within a single environment, there may be more than one version of a standard being used concurrently - I don't know who else is working on this topic, but it strikes me that it has BIG implications for a Business Architecture that seeks to maintain consistency, reuse and standards adoption improvement.
- The current business model where organizational members are entitled to all of the standards does not lend itself to identifying customers interested in product lines. No ready means to gain insight into who is use what standards for what reason and whether they are only using them as a jumping off point for local information exchange or whether the standards they adopt are sufficiently specific to their use case that they can adopt them directly. What does "fit for purpose" mean anyway?
- Different end-user stakeholders may have different opportunities and constraints and readiness to participate in interoperability initiatives - Business Model processes may need to be adapted to be responsive to requirements for interoperability standards coming from different categories of end user environments - Andy and Zoran's work is likely applicable here too.
- Collaboration environments can change business processes - I think we need to state assumptions about what form of collaboration is being used by which processes to distinguish real-time virtual, asynchronous virtual, real-time f2f because they have different penetration into HL7's increasingly global virtual community.