HSSP_Corner_Logo.jpgHealthcare Services Specification Project

hl7_logo.gif
The Healthcare Services Specification Project (HSSP) is a group developing health industry SOA standards to promote interoperability across systems that support health care. HSSP isomg-home.gif specifically focused on identifying services that will have the maximum impact on interoperability, and works within the health community to identify the areas of need. HSSP is underpinned by a set of guiding principles that keep our work directed toward practical, viable, business-relevant solutions.

So, what is HSSP's vision? Many health organizations are currently planning, implementing, or using service-oriented architecture as a key approach to realizing their health IT investments and in integrating systems within their organizations. They are facing tremendous challengs. Standards are in place within the technical stack, such as web services, ostensibly making integration easier. What is unfolding, however, is that this integration is tremendously difficult.

Each supplier has their own approach to solving problems, even within a particular area of interest. While this marketplace competition is a good thing, absence of standards means that any system change incurrs significant integration pain. HSSP is about creating standard interfaces that define the protocol for interacting with these systems. HSSP specifications would not limit what suppliers do or how they add value -- they are simply defining an industry-standard way for "asking" and "answering" within the context of the SOA Service being specified. This allows users to plug-and-play, minimizing integration burden. To vendors, HSSP specifications make it easier for their product to replace an existing component, with the process promoting competition based on service delivery and not lock-in.

HSSP produces three types of deliverables:
  • Service Functional Models in the form of balloted standards that define the functions, behaviors, and information needs for health SOA services
  • Technical Specification Standards that further refine the Service Functional Models to address middleware platform, environment, etc.
  • Implementation Guidance as informative references to assist consumers of the above standards in implementing them within their organizations

Specifically monikered as a "project' because projects have deadlines and deliverables, HSSP has created an environment fostering collaboration across multiple organizations, HSSP uses its guiding principles, a fully-documented methodology, and an approach to enable each organization participating to effectively contribute while minimizing red-tape.

Currently there are several organizations engaged with HSSP Activities:

Health Level 7 (HL7) is leading HSSP Service Functional Modelling (SFM) activities. SFMs are produced by the stakeholder community, identifying what the service being specificed needs to do, but not how it is to be done. HL7 is a diverse, international community of stakeholders involved in healthcare and interoperability, making it a good community to foster the SFM work.

The Object Management Group (OMG) is leading HSSP's techincal specification activities. The OMG has a technology adoption process that ensures that its specifications are implemented in conjunction with their evolution, ensuring that the end products are viable and practical. In fact, specifications do not become Standards until implementations have been demonstrated. The OMG community comprises vendors, users, and technology companies with a strong software engineering, architecture, and implementation focus.

Open Health Tools (OHT) is a community that is developing open-source healthcare software using a licensing model that is commercially-friendly. OHT has made commitments to engage with HSSP, implementing open-source reference implementations of the technical specifications adopted through the HSSP process, ensuring that viable software solutions are marketplace-available that conform to HSSP standards.

Who is involved?

HSSP has active involvement from across the health sector. There are participants from healthcare provider organizations, healthcare payers, public health institutions, and pharmaceutical companies. Also engaged are representatives from Governments, vendors, and integrators.

HSSP has tended to attract archtiects, designers, and practitioners that are involved in health interoperability work, particularly those with strong interests in SOA, web-services, and Enterprise Architecture. A common theme underpinning the HSSP community is a desire for open standards that promote industry consistency around behavior without limiting implementation creativity, deployment flexibility, and versatility in usage of the work.

HSSP has a strong international constituency and enjoys active involvement from Europe, North America, and Australasia. In support of this diversity, all of the work is publicly available through our web-presence, and teleconferences are scheduled with international sensitivity making compromises to foster the broadest possible participation.

What have we done?

Since our formal inception in January 2006, we have produced:

Service Functional Models:
Entity Identification Service Functional Model (addresses ability to determine the identifier for people, things, etc.; like an MPI service)
Retrieve Locate Update Service Functional Model (specifies the functions required for a query and update capability)
Decision Support Service Functional Model (describes the core functions needed to support clinical decision support)

Implementation Guidance:
SOA4HL7 (defines a migration strategy

Technical Specifications:
Entity Identification Service Initial Submission (work in progress -- the first-iteration candidate of the EIS technical specification for SOAP)
Retrieve, Locate, Update Service Initial Submission (work in progress -- the first interation candidate of the RLUS technical spec for SOAP)

Other Documents:
HSSP Service Specification Framework (the methodology HSSP follows for service specification and definition)
HSSP Reference Architecture (an informative reference describing how HSSP services are envisioned to fit together and within an organization)
HSSP Roadmap (outlines our current and planned service work)

All formal artifacts produced from HSSP as standards or balloted content can be found on our standards page.

What are we trying to do next?

New activities are added to HSSP via two distinct paths. HSSP has developed and constantly revises a Roadmap document. This Roadmap outlines what the group has identified as critical-path priorities, and addresses these incrementally as resources permit.

Ultimately, HSSP is a contributory community, meaning that the activity on its own has no resources or budget. HSSP is responsive to its membership, whom ultimately make the contributions and determine the priorities. If orgnizations see value in activities, they get done.

HSSP is willing to initiate new activities at any time, so long as the following conditions are met:

1) There is a leader willing to take personal ownership of the task.
2) There is a community supportive of the work. This doesn't need to be extensive, but we ask for 3+ organiztaions to ensure that there is sufficient diversity necessary to produce a quality internerational standard.
3) There is "day job" alignment with the core participants. Our experience illustrates that seeing this process through requires work and support, and that organizations working on the activity as part of their "day job" produce better work driven from their own organizational needs and interests.
4) Agreement to follow HSSP processes. This ensures consistency across our work and consistency in quality. Participants also agree that if they identify problems or issues with our process, that they surface them and allow us to correct (in lieu of splintering their effort and diverging from us).
5) Clear articulation of objective, attainable in 12-18 months. HSSP is very focused on producing results, and on incremental improvement over time. Any activity not well defined and/or not attainable in a reasonable timeframe is less likely to succeed.

Once a group has met the above conditions, they are formally chartered as a subproject. Subprojects have significant autonomy, determining their own timelines, processes, and sub-culture. They have general accountability to HSSP, but have the freedom and flexibility to innovate and adapt to their specific situation. HSSP has worked very hard to establish a "high-trust" environment, where the community is there to support sub-projects and not to micromanage them.

How do I get involved?

All HSSP activities are open to public participation and publicly visible. All content is on our wiki. The following are recommendations to get invovled:

  • Check the call schedule on the Event Calendar and dial-in. All calls are open, and you are welcomed.
  • Identify a small piece of work to which you would like to contribute and volunteer. Every contribution is valuable.
  • Attend a working meeting. HSSP meets at HL7 and OMG meetings. Details of our meetings are available at the event center.
  • Attend an educational session. Approximately 4-6 times annually HSSP hosts tutorisal or educational events.
  • Contact a community member. We have contact names listed by specialty, activity, and geography. All contacts listed on the HSSP site have put their names forward for open contact, and would be happy to help you navigate to your area of interest.