Page tree
Skip to end of metadata
Go to start of metadata

1.Publication Request

1.Publication Request

2. Standards Material/Document


4. Date of Request

Sep 17, 2019

5. Use Period

2 years

6. Reason for extension, timeline, and actions

7. Original Publication Date

8. End date of the current STU period

9. Length of the requested extension

10. Review Process

11. HL7 Work Group making this request and date

Services Oriented Architecture

11a. Requesting WG Date

12. URL of approval minutes

13. HL7 Product Management Group


13a. Management Group Date of Approval

14. URL of approval minutes

15. Is the artifact ready for final publication?


16. If not ready, please describe remaining steps.

17. Tool name used to produce the machine processable artifacts in the IG

18. The name of the “IG artifact” within the context of the above mentioned tool.

19. Published Name of the Standard for which request is being made

20. Balloted Name of the standard for which request is being made

HL7 Health Services Platform (HSP) Marketplace Release 2 STU 1

21. Requested name for published standard

HL7 Health Services Platform (HSP) Marketplace Release 2 STU 1

22. If CMET, list IDs balloted

23. Project Insight Number


24. Document Realm


25. Ballot cycle in which the document was successfully balloted


26. Results of that ballot (following reconciliation activities):

26. Results of that ballot (following reconciliation activities):

(not needed for errata, STU extension, or unballoted STU update)

27. Affirmative


28. Negative


29. Abstentions


30. Not Returned


31. Total in ballot pool


32. Date on which final document/standards material was supplied to HQ

Sep 18, 2019

33. URL of publication material/ SVN repository

Will send email to publishing.

34. Publishing Facilitator

Lorraine Constable

35. Special Publication Instructions

Would be easier to hand off containerized version. (hspc/marketplace-documentation)

36. URL of ballot reconciliation document

37. Has the Work Group posted its consideration of all comments received in its reconciliation document on the ballot desktop?


38. Substantive Changes Since Last Ballot?


39. Product Brief Reviewed By

SOA WG, Tuesday Q3, September 2019 (Atlanta, GA)

40. Date Product Brief Reviewed

Sep 17, 2019

41. Has the Product Brief changed?

42. Product Brief

42. Product Brief

43. Family

44. Section

Implementation Guides, Rules and References

45. Category

Decision Support Regulated Products Security and Privacy Services Other: (Please describe)

46. Please Describe the Category

This is an implementable specification agnostic to clinical domain.

47. Parent standard

48. Parent Standard Status

49. Update/replace standard


50. Common name/search keyword


51. Description

The Marketplace API specification serves as a building block for orchestrating the exchange of such services and executable knowledge. Products deployed in an enterprise architecture are constituent building blocks in a larger information technology (IT) ecosystem. The deployment and runtime characteristics of each individual building block as well as underlying infrastructure naturally vary across organizations, requiring each service deployment to be further tailored to local IT needs. The process of doing so also varies and is generally considered a normal part of "implementation time" and total cost of ownership (TCO) calculations for incorporating a new service into the enterprise. This lack of infrastructure pre-coordination can result in extremely long IT implementation cycles for any capability to be added to, or changed within, an architecture, especially when underlying infrastructure is completely proprietary to the local institution and/or vendor platform. Burdens of local implementation are confounded by the rise of interest in portable declarative clinical knowledge such as HL7 CDS Knowledge Artifacts and Fast Healthcare Interoperability Resources (FHIR) Clinical Reasoning, as well as libraries of directly executable clinical knowledge such as HL7 Clinical Quality Language (CQL). Any potential reduction to time spent in discovery, evaluation, update, and other changes to enterprise service oriented architectures (SOAs) – thereby increasing the agility of the organization -- is of great value to the HIT community. For organizations willing to enable deployment of these individual knowledge artifacts, direct savings could be substantial.

52. Targets

52. Targets

These are categories of potential users, implementers, or other interested parties such as those that are indicated on the Project Scope Statement under “Stakeholders/Vendors/Providers”. Select those that are applicable, or suggest others:

53. Stakeholders

Standards Development Organizations (SDOs)

54. Vendors

EHR, PHR, Health Care IT, Clinical Decision Support Systems

55. Providers

Other (specify in text box below)

56. Benefits

The Health Services Marketplace addresses the problem of exchanging backend service implementations in a vendor-neutral manner, which is necessary to exchange executable artifacts interoperably to plug-n-play across SOAs. In broad strokes, it is the server-side equivalent of SMART-on-FHIR (SoF), as SoF only concerns client-side app integration and also does not address client-side deployment requirements of web applications, not uncommon in health IT (HIT) enterprise. The design principles are inspired by the business processes that made other computing ecosystems, such as the (all proprietary) Apple, Google, and Amazon app stores successful. This allows:

- HIT orgs to search for new services across *all* participating vendors, and deploy them in a 100% automated fashion into on-prem, cloud, and/or hybrid infrastructure, using 1 or more Marketplace instances in any public/private combination.
- Developers to directly submit new (and update existing) service builds.
- Marketplace operators to curate, review, and publish vendor submissions.
- Compliance validators to automate certification activities.
- All parties to optionally authenticate with existing SSO credentials needed for SoF apps/architectures.

57. Implementations/Case Studies

Logica Health (formerly HSPC) holds a reference implementation of both the service API specification and optional front end client application.

58. Development Background

The Marketplace specification has been developed agnostic to the underlying service and content standards with a flexible metadata format. Long term, this should allow independent software vendors and content authors to submit works across competitive distribution channels more easily than proprietary app stores. Likewise, providers and HIT stakeholders should be able to discover and deploy those products more fluidly and consistently than existing disjoint methods.

1 Comment