• Work Group FHIR Infrastructure Content
• Examples
Standards Status : Informative
• Detailed Descriptions
• Mappings
• Profiles
• Extensions
• Search Params

3.0 8.33.8 FHIR Exchange Module Resource Invoice - Mappings

Introduction / Index

Financial Management 3.0.1 Work Group

Maturity Level : N/A

Standards Status : Informative

Security Category : Patient

Compartments : Device , Patient , Practitioner , RelatedPerson

Each of these approaches can be used to exchange information, and each has its own strengths and weaknesses and applicability. Note that applications are allowed to use any other method to exchange resources; the methods described in this specification are the common methods that are used enough to justify Mappings for the effort invoice resource (see Mappings to describe or standardize their use. Other Standards for further information & status).

3.0.1.1 8.33.8.1 RESTful API FiveWs Pattern Mapping ( http://hl7.org/fhir/fivews ) Most implementers focus on RESTful API . This is a client/server API designed to follow the principles of RESTful design

for C reate, R ead, U pdate and D elete operations, along with S earch and E Invoice xecute (Operations) support. The RESTful API is a general-purpose interface that can be used to push and pull data between systems. Which is appropriate depends on architecture and deployment considerations. The RESTful API also supports Asynchronous Use
identifier	FiveWs.identifier
status	FiveWs.status
type	FiveWs.what[x]
subject	FiveWs.subject[x]
actor	FiveWs.actor

and GraphQL .

3.0.1.2 8.33.8.2 Messaging Workflow Pattern ( http://hl7.org/fhir/workflow ) In addition to the RESTful API, a messaging exchange framework

This specification also defines a document based exchange framework , where content to be exchanged is wrapped by a Composition

is documented, which supports exchange between systems by sending routed messages from system to system. This exchange can be implemented on the RESTful API or using some other messaging technology. Implementers should note that the messaging framework is not provided to fill any functional deficiency in the RESTful API (or vice versa), these frameworks are provided to allow implementers to choose how to exchange content based on their own architectural and deployment considerations. Messaging may be more suitable for exchange between disparate organizations with low levels of process integration and/or trust. 3.0.1.3 Documents Invoice	Event
type	Event.code
subject	Event.subject
note	Event.note

that provides the context of the content, and that has a fixed presentation for a human reader. The document framework is provided to help with computer-assisted human to human communication uses - which are not uncommon in healthcare. Typically, exchanging documents is associated with exchanging clinical information across clinical governance borders, while data-based exchange using the RESTful API is appropriate within where there are well established clinical governance arrangements.

3.0.1.4 8.33.8.3 Services / SOA HL7 V2 Mapping ( http://hl7.org/v2 ) In addition, this specification describes the use of FHIR in a services framework

Another way to make use of the resources defined 3.0.2 Security and Privacy All forms of data exchange should be appropriately secured. This requires the following: Only the parties to the exchange can access the communication The parties are authenticated and authorized as required Access control always checks that the only the appropriate data is exchanged Appropriate patient consent has been obtained for the exchange This subject is described further in the Security Page. With regard to the RESTful API, implementers should always consider the Smart App Launch

(e.g. a SOA). Note that any use of any of the above approaches in production is a 'service' by some or many definitions. The services description provides context regarding the use of FHIR (and particularly the RESTful API) in a wider enterprise architecture. 3.0.1.5 Database / Persistent Store Invoice	FT1
identifier	FT1.2
status	Varies by FHIR is domain
cancelledReason
type	FT1.7
subject	PAT in proximity to store them natively FT1 segment
recipient	PV1 in a database proximity to FT1 segment
date
creation
period[x]
participant	EVN.5 or persistent store, where different applications by domain
role	Varies by domain
actor	EVN.5 or modules write and read the resources as part of their implementation. Using resources in this fashion is described here. by domain
issuer	N/A
account
lineItem	EVN.5 or by domain
sequence
serviced[x]
chargeItem[x]	EVN.5 or by domain
priceComponent	EVN.5 or by domain
totalPriceComponent	EVN.5 or by domain
totalNet	FT1.22
totalGross	FT1.22
paymentTerms
note	NTE

protocol as part of the overall secure API approach

3.0.3 8.33.8.4 Developmental Roadmap RIM Mapping ( http://hl7.org/v3 )

Trial-Use Note: Note to balloters: There's some interest in standardizing the use of ProtocolBuffers directly in the specification itself ( basis ). Ballot comments are welcome.

RESTful API Invoice	This is stable and currently being balloted as Normative. No breaking changes are expected. No significant development is planned, but HL7 will continue to respond to user experience Act[moodCode=EVN]
Messaging     identifier	.identifier
Messaging has only be implemented in a few projects; some of the infrastructure has not yet been used in production. It is not clear whether significant development will be needed or appropriate     status	.status
Documents     type	.code
Documents have mostly only been used in prototype projects, though there is considerable impetus around implementation at this time. No significant development is planned, but HL7 will continue to respond to user experience     subject	.participation[typeCode=SBJ].role
Services     recipient	.inboundRelationship(typeCode=COMP].source[classCode<=PCPR, moodCode=EVN]
At this point in time, it's not clear whether further work is required or appropriate in terms of service orientated architecture / enterprise integration. HL7 will continue to monitor implementer experience and feedback     participant	.participation[typeCode=PRF].role[scoper.determinerCode=INSTANCE]
Database / Persistent Storage         role	.participation.functionCode
This is a new area with considerable action at this time, and many production implementations, though RDF itself is not getting much use. At this time, HL7 is monitoring implementer experience and feedback to see whether additional standardization is required         actor	.player
issuer	.scoper
lineItem	.participation[typeCode=PRF].role[scoper.determinerCode=INSTANCE]
chargeItem[x]	.player
priceComponent	.participation[typeCode=PRF].role[scoper.determinerCode=INSTANCE]
totalPriceComponent	.participation[typeCode=PRF].role[scoper.determinerCode=INSTANCE]
note	.inboundRelationship(typeCode=SUBJ].source[classCode=ANNGEN, moodCode=EVN].value[xsi:type=ST]