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

Publication Request

Publication Request

Standards Material/Document

STU

Date of Request

Sep 17, 2019

Use Period

2 years

Reason for extension, timeline, and actions

Original Publication Date

End date of the current STU period

Length of the requested extension

Review Process

HL7 Work Group making this request and date

Services Oriented Architecture

URL of approval minutes

https://confluence.hl7.org/display/SOA/SOA+Sep+2019+Minutes+Atlanta+WGM

HL7 Product Management Group / date

N/A

URL of approval minutes

Is the artifact ready for final publication?

No

Description of qualifiers for publication.

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

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

Published Name of the Standard for which request is being made

Balloted Name of the standard for which request is being made

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

Requested name for published standard

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

If CMET, list IDs balloted

Project Insight Number

1436

Document Realm

Universal

Ballot cycle in which the document was successfully balloted

2019-sep

Results of that ballot (following reconciliation activities):

Results of that ballot (following reconciliation activities):

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

Affirmative

18

Negative

12

Abstentions

54

Not Returned

15

Total in ballot pool

99

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

Sep 18, 2019

URL of publication material/ SVN repository

Will send email to publishing.

Publishing Facilitator

Lorraine Constable

Special Publication Instructions

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

URL of ballot reconciliation document

http://www.hl7.org/documentcenter/public/ballots/2019SEP/reconciliation/recon_hl7_hsp_r2_d1_2019sep.xls

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

Yes

Substantive Changes Since Last Ballot?

Yes

Product Brief Reviewed By

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

Date Product Brief Reviewed

Sep 17, 2019

Has the Product Brief changed?

Product Brief

Product Brief

Family

Section

Implementation Guides, Rules and References

Category

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

Please Describe the Category

This is an implementable specification agnostic to clinical domain.

Parent standard

Update/replace standard

Supercede

Common name/search keyword

"marketplace"

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.

Targets

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:

Stakeholders

Standards Development Organizations (SDOs)

Vendors

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

Providers

Other (specify in text box below)

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.

Implementations/Case Studies

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

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