editing disabled

HSSP Frequently Asked Questions

(Last Updated: Dec 2006)

1). Will the standards being produced from HSSP be HL7 or OMG standards? HSSP will be producing both HL7 and OMG standards. Within the HL7 community, HSSP is producing "Service Functional Models" that will be technology-independent and balloted as HL7 standards. These "Service Functional Models" will then be adapted into OMG Request For Proposals that result in OMG Standards.

2). Do I have to be a member to participate? No. While there are benefits to being a member of HL7 and OMG that give you rights during the adoption process, and non-members do not have the ability to vote on many issues. Also, there are parts of the OMG technology adoption that would require membership to directly shape the technical specifications. That said, all of our calls are open to contribution from anyone choosing to participate and newcomers are welcomed.

3). Do I need to join both HL7 and OMG to participate? If your primary interest is in identifying what the services should do, then HL7 is the most apporopriate community to join. If your interest is in the technologies and how the services will work, then OMG is the right community to join. Many organizations are members of both HL7 and OMG.

4). What commitment is expected of participants? For all standards work, organizations tend to get out of their participation what they put in. HSSP subgroups tend to have hourly calls every week, with an additional 30 minute status call for the entire project semi-monthly. Much of the work occurs during call times, though additional effort is always appreciated. HSSP realizes that participation is an investment and will do everything to ensure that you are achieving business value from your participation.

5). Why develop functional specifications?
The functional specification seeks to detail the “behavioral requirements that specify how a proposed system will process and handle information. It details the features and rules that must be present to fully implement the functionality desired.” [From the Sparx Enterprise Architect]

The functional specification is extraordinarily “vanilla” in its approach and in its language. It is intended to broadly define a whole host of issues, and necessarily loses some of its power to recommend. But it is the first step in a process.

6). Aren’t functional specifications worthless?
You can make a case that functional specifications aren’t very useful, and you’d be correct in a lot of cases. However, HSSP SFMs are considered mandatory for three reasons:
1) They support the cross organizational work being done by HSSP, and creates an artifact that can span organizations
2) They give healthcare at large a place to define their needs and requirements for a component that nearly everyone agrees is necessary
3) They define a service layer that surrounds many other mechanisms and systems that are already endorsed by HL7.

7). Where are technical specifications produced?
Technical specifications will come from the work done by HSSP within OMG. SFMs provide the grounds for an RFP issued by OMG to industry. The RFPs issued by OMG solicit industry submitters, who are ultimately the authors of technical specifications. The OMG reviews candidate submissions and selects the submission best supporting the RFP. Submitters often collaborate to produce a joint submission.

8). Why the focus on services?
It is beyond the scope of this document to explain services in depth. Services are coarse-grained structures by definition, and can wrap a variety of organizational artifacts, including data, business processes, registries, and more.

In short, focusing on the service layer of function and implementation gives HSSP the leverage to move away from needing to rigidly define an organization’s internal structures. Instead, it focuses on the issue of interoperability while adhering to the quality of simplicity.

9). What is HSSP?
HSSP stands for Healthcare Services Specification Project.

10). Why collaborate between HL7 and OMG?
Because both organizations are necessary but not sufficient to achieve:
1) Healthcare buy-in
2) Industry buy-in
3) A truly comprehensive approach to standardization to achieve interoperability.