HL7 SOA SIG Mtg

Monday Q3

Ken Rubin opened the meeting and reviewed the agenda

EIS and RLUS were voted as DSTU in September 2006, the period ends in September 2008, so we need to discuss what needs to be done to move forward to Normative

Ken provided an overview of HSSP, and reviewed the HSSP Principles

Charlie Mead suggested adding an agenda item to discuss the relationship between whether HSSP and HL7 SOA WG are one and the same. At one time, these were clearly two sides of the same coin, and the processes were closely linked. At question is whether the roles might need to separated / clarified. For example, do all SFMs need to go through OMG, or can they go through simply the HL7 process, and not OMG. In other words, HSSP is a separate organization. Scheduled discussion for Tuesday Q2.

Held co-chair elections: Elected Galen Mulrooney (17 votes), and John Koisch (11 votes)

Reviewed the Charter

The discussion around SOA WG scope vs. HSSP came up again, in that it was felt that half a quarter is not enough time. Moved the Open Health Tools discussion to Thursday Q3, splitting it with the Education and Outreach topic. Thus Tuesday Q2 is wholly dedicated to SOA WG scope vs. HSSP

Discussed the recent SOA in Healthcare conference in Chicago. Those who attended provided their impressions, and requested input for planning for the next conference.

Ken walked through the HSSP Orientation Deck.

Monday Q4

JKoisch introduced EIS, RLUS, and DSS as SFMs that were passed in 2006 and 2007. AKirnak gave updates on the RFPs that are happening through the OMG. Submission deadlines are in June, 2008.

Discussion about the nature of the services.

Tuesday Q2

Note: These minutes are combined notes from Galen Mulrooney and Rich Rogers.

Initials used below are:

AK:Alean Kirnak

AW:Ann Wrightson

CD:Ciaran DellaFera

CM:Charlie Mead

DJ:Don Jorgenson

DR:David Rowlands

GM:Galen Mulrooney

JK:John Koisch

JQ:John Quinn

NO:Nancy Orvis

RP:Ron Parker

CM: HSSP is successful. We now need clear definition of SOA WG vs. HSSP due to three additional drivers (roughly in order of occurrence, not in order of importance):

  • HSSP rightfully is starting to reach out to multiple organizations to join the process which currently says that HL7 creates the SFM and hands them over to OMG. Referenced Chicago meeting where HSSP reached out to establish relationships, but HL7 SOA WG is not empowered to reach out to other organizations. HL7 board must be involved in any relationship forming with other organizations by its WGs.
  • Does not want to scrap relationship with OMG. But currently, the analysis is performed only in OMG. But if a group doesn’t want to work with OMG, and wants to submit artifacts solely through HL7 (SFM and PIM, for example), there is no mechanism within HL7 to fulfill the function. HL7 needs a more concrete deliverable.
  • The CTO (John Quinn) is requesting that the ARB develop a nominal Enterprise Architecture specification that is based on services. Note, not to replace messaging but to acknowledge that HL7 is becoming more service aware. Need to define what it means for HL7 to produce services.

Can the SOA WG create and manage PIMs?

Hypothetically, who will be the M&M for SOA? Should that be the SOA WG?

Discuss how can we delineate and define the SOA WG wrt to HSSP so that is clear to the outside community who is doing what.

Needs to be a clear delineation when a relationship with another organization, whether that’s being done by HSSP or SOA WG

JK: If this direction is going to be viable, SOA WG is going to need to take on some of the things that aren’t being done

JQ: Two threads:

  • IHE reachout by HSSP – need to communicate to HL7 Board members that own relationship with that group
  • The Board wants the ARB to put SOA in the middle of the reference architecture.

DR: HSSP must not be divorced from HL7 or OMG…. Warned against having duplicative standards among the SDOs – it leads to divergent paths.

JK: problem is not that HL7 is creating duplicate specifications; the problem is that HSSP is perceived as the only way that SOA specifications can move forward. Not just uptake, but also the machinery and supporting elements need to be defined separate from HSSP. HL7 needs to make decisions on what path to take. HL7 needs to produce the pathway and methodology to create the specifications that can be consumed by others.

NO: It sounds like you’re trying to make the SOA group to be more conceptual (like M&M) rather than action-oriented, producing actual artifacts via OMG. Let’s be clear on SOA WG’s mission.

AW: Appreciate the wish in the market for clarity on what the different types of specs we build are for – need adaptability. Need to be uncompromising on semantic interoperability with full respect for what our market is trying to do. Suggest that the issue is an administrative one – we must find administrative means to enable success.

DJ: Asked whether the proposal is that HL7 build SOA specifications rather than OMG?

CM: Not suggesting that we build PSMs, am suggesting that we build PIMs.

DJ: What’s the vision for SOA WG going forward then? Are we asking to make it clearer what options are available?

CM: Up until now, HSSP is undertaken the responsibility to create service specifications….

Imagines SOA WG’s agenda going forward: HSSP forming relationships, evangelizing services, SOA WG actually undertaking the mechanisms and mentoring the HL7 WGs in building SFMs, similar to Modeling and Methodology in v3

GM: If you’re advocating that SOA WG act like M&M, why have them as two separate groups? While aspects of the two groups are similar, they really have rather different missions….

JQ: The TSC understands that the organization structure of committees needs attention. It’s a work in progress, reorganization discussions on the table.

AK: PIM and PSM creation is very iterative – hard to separate. HL7 should debrief HSSP for lessons learned.

CM: SFM is a requirements document – PIM is an analysis document. Need an alternate path to get to PSM. HL7 needs to produce something closer to implementable than we produce today

RP: I hear that we have a requirement to have some kind of capability that allows us to test that what we’re building is viable - feet on the ground, test the standards in the practitioner community. Another requirement is the need to make the transition without losing tactical value of HSSP and how we produce a SOA based Enterprise Architecture with which the WGs can engage. Another requirement is how do you capture specifications and render them, per Jane Curry?

AW: need a charter that sets the scope of the SOA WG: The SOA WG has two roles: 1) drive HSSP; and 2) SOA governance within HL7. Need to address both functional and informational perspectives.

CM: SOA WG would coordinate with ARB….

JK: would add notions of conformance and compliance – need to build structure for conformance and compliance.

AK: some specific suggestions: Much more detailed explanation of operation semantics at the PIM level– realized when creating PSM – need a closed loop. Same for architectural issues – need feedback loop from implementers back into HL7. Also need a common information model – what is the role of the DAM and how does it plug in to every thing else?

CM: NCI wants to bring their own lessons learned from their SOA efforts back into HL7

GM: Three thoughts:

  • Need to remember why the demarcation between HL7 and OMG exists: they have different IP models. That’s why there are clear ownerships of the artifacts. However, this does not preclude an iterative approach back and forth between the two organizations.
  • Alean mentioned the need for an information model. Fully agree, as this allows for internal consistency among artifacts. The VHA has such a model – the VHIM; NCI has one two – the BRIDGE. However, it should be noted that the current set of tooling does not support such an “uber model” of HL7.
  • David mentioned avoiding duplication of services by multiple SDOs. Agree wholeheartedly. We need a taxonomy of services

KR: Regarding the transition, would support PIM creation in HL7 if we can do it correctly – need to address the required skill set, consider the ability to bring to ballot. Note that a cultural change is required. Regarding Ann’s suggestion of a way forward – would like to see a motion for language developed around her ideas – appeared to be support in the room for this. In other words, would like to see an action item that we define the SOA Governance.

RP: We are rapidly converging around a business model – look at the telecom industry, very successful; they achieved this via adoption of ubiquitous standards. If you took the standards away from them, they’ll fail. That’s the huge challenge for healthcare. We need to get to that point, and we need widely accepted standards to get there.

NO: There will be a mixed model – it’ll be 15 – 20 years before we’re ALL SOA, until then, we’ll be in a mixed mode.

CD: We can’t ignore this issue. Healthcare traditionally lags in IT. We need to incremental-ize. Consider the experience that Boyd Carlson of Duke relayed at the “SOA in Healthcare” conference: he described an incremental move toward SOA. We need a cohesive modeling approach.

JK: SOA: technology agnostic, semantics

RP: SOA WG needs to create declarative statements around incremental approach. We need to provide guidance for creating specifications. We need to define the philosophical “attitude”, definition of success.

Motion: Accept in principle the approach of defining the scope of SOA WG work as participation in the HSSP plus other defined areas of work. A scope statement will be formulated and brought to the SOA WG for approval. Ken Rubin /Ann Wrightson. Approve/Abstain/Against: 19/0/0.

Tuesday Q4

Discussed RLUS.

Debated the value of expressing Template metadata in MOF and the merits of doing so with respect to

Motion: “There is a broad consensus among the SOA WG representatives of HSSP present that a Template Registry Service would be useful to the community. We have identified potential organizations that may have interest to contribute. We also see the potential value of the implementation as fostering further standardization and service development.”Ken/Ann 7/0/0

WednesdayQ1 and Q2

Discussed the Practical Guide for SOA document

Suggestion was made to map services to the HITSP EHR Functional Models

Discussion about the difference between services and interfaces. Worked on the matrix table.

Decided that we need a set of layers that bring context and convergence as the reader moves down the layers

Describe the HSSP Granularity

Need some notion of how you move into services (i.e, transition plan). Need something like this in the summary.

Business case for soa

Brainstormed 5 or 6 questions that the document is trying to answer:

  • What’s the difference between WS and SOA?
  • Can we do this without a full business model?
  • What am I supposed to do with the HSSP services – in other words, so what?
  • How do I relate my real-life functions to generic HSSP Standards (i.e., retrieve Lab result vs. RLUS).
  • How does this relate to my existing investments?
  • How does SOA relate to HL7?

Discussed the audience

Built a business-based scenario that describes the predicament that the sample health finds itself in. So that we set the scene where each architectural piece we bring up later addresses.

Adjusted the matrix accordingly.

WednesdayQ3

Provided a briefing on the status of HSDS. Bottom line is that there has not been enough interest among the membership to move this forward. There is a possibility that we might be able to jointly work with other SDOs, such as ASC X12, but need to tread carefully here – any such collaborations will need to be approved by both boards first. Resolved to contact various potential interested parties and ask them to task some resources on a temporary basis to knock this out. Potential parties include payers, larger providers, Canada Health Infoway, Canadian provinces, MITA, eWG.

Continued the discussion on the Practical Guide for SOA document. Fleshed out the matrix.

WednesdayQ4

Discussed the status of the PASS SFM. There is a concern that there may be a mismaWGh between the scope of the PASS project and Security WG. Need to set up a joint meeting with the Security WG in Vancouver. In the meantime, we’ll set up a joint call, perhaps with a Live Meeting, eWG.

Ken to contact Mike Davis to determine if VHA can assist on definition as well as assist with help on the SFM.

ThursdayQ1

The TSC has asked the ARB to take responsibility of the Dynamic Model (DM). MnM is in the process of documenting the current DM in the Core Principles documents. This includes things that are now true but have not yet been documented fully or at all.

The ARB would like to move this forward rapidly. ARB submitted a proposal to the Foundation and Technology Steering Division, which asked for the project to re-formatted into the new Project Template, and re-submitted, which will be done.

CMK The requirements definition is pretty well done and the framework definition needs to get started. It is not our intent to force HL7 users to bind to any particular technology stack.

ThursdayQ2

ThursdayQ3

Discussed SOA in Healthcare conference

Might want to have one non-healthcare speaker, but not more than one. Perhaps someone who can speak better to healthcare but can bring experiences from other industries

Maybe have an optional SOA 101 session the day before – this prepares people first, and also allows the speakers to properly assume a basic knowledge

Maybe instead of a conference theme, have a use case to be tackled each day

Maybe have an interoperability / engineering track…?

Maybe have an track on organizational adoption / transition strategy track or day theme?

Ann warned against having to make people choose between what they were interested in verses those things they needed to hear.

Resolved that the SOA WG would like to thank Alan Honey for his hard work and dedication to the SOA WG. Ken/Ann 8/0/0

Friday Q1 (Joint meeting with IHE)

Keith Boone walked us through their Wiki showing their efforts related to SOA

Ken Rubin walked through the Practitioners Guide.

Discussed the HSD work. Advised to look into the work that ISO WG 215 is doing. See ISO 21091

Discussed joint efforts regarding EIS and IHE PIX/PDQ

Discussed Patient Care Coordination

IHE is focused this year on Care Management and Clinical Decision Support

Takeaways:

  • HsSP invites contributions to the Practitioners Guide
  • EIS/PIX/PDQ
  • Admin / Finance HITSP – looking for Provider Identification Keith to connect Ken with co-chairs – Ken to send email to Keith
  • ISO/215 work on hc directories be aware of 21091
  • Show how HSSP specs / IHE Profiles fit together
  • Talk about this in the practical guide
  • Karen could help
  • Other HIMSS can bring in resources
  • IT Planning could work with HDDP to plan how to work together
  • Didi can task this to ITI Planning – Mike Nussbaum / Charles Parisot
  • Care management 12 content / RLUS follow-on discussion
  • Do this again in Vancouver

“Come for the use case - Stay for the architecture”