Technical Overview, FHIR RESTful API
The Canadian FHIR Pharmacy Claims standard is an update to the existing CPHA standard that has been in place for over 25 years in Canada.
As Pharmacy Management Software (PMS) vendors, Claims Processors and Ajdudicators will need to upgrade from the existing standard, detailed mappings from the existing CPHA message standard to this new FHIR standard are included as part of this Implementation Guide.
This specification will align, where possible, with other IGs that may be used by Pharmacy Management Systems (PMS), including the Canadian Core and PrescribeIT.
The PCS standard is built upon the HL7 FHIR R4. FHIR is an international standard for exchanging health care record and is being widely adopted across Canada for emerging healthcare standards. A Canadian registry of projects and specifications is published on Simplifier and, for interest, may be found HERE
FHIR provides a collection of well-defined interfaces for interoperating between two applications. Transactions are performed directly on the server using an HTTP request/response. The FHIR RESTful APIs are described in full within the FHIR specification, found HERE. and HERE
For processing Pharmacy claims, a "messaging" interface will be used. The Operations are invoked by performing an HTTP POST to the operation's end-point. Each implementer will publish their end-point [base] to their implementation partners. The response will be a standard HTTP response indicating whether this was successful. If successful, an HTTP 200 and message bundle will be returned containing the payload details. An HTTP status code of 4xx or 5xx indicates an error, and an OperationOutcome will include details. This follows the FHIR [Messaging Framework](**insert link).
[POST [baseurl]/Claim/$submit](insert link) https://build.fhir.org/claim-operation-submit.html - UPDATE FOR R4
Invoking Operations via Messages
A message can be used to invoke an operation as defined for a RESTful interface using an operation definition. To invoke an operation using a message:
The requester sends a message (a bundle with type = message, and a message header resource)
- The message header has an event.system of urn:ietf:rfc:3986.
- The event.code is the URL from the operation definition OperationDefinition.url.
- The MessageHeader.focus refers to a Parameters resource
- The parameters resource is populated appropriately as specified by the nominated operation definition.
- The recipient executes the operation as specified, and then:
The receiver sends a message (a bundle with type = message, and a message header resource)
- The message header has the same event as the original message
- The MessageHeader contains a response that refers to the original request message, and a code for the outcome, with details if the operation failed
- The MessageHeader.focus refers to a Parameters resource
- The parameters resource is populated appropriately as specified for the response by the nominated operation definition
- If the operation definition specifies a single return, then this is returned as the target of the MesssageHeader.focus directly
Key Technical Enhancements
| Number | Topic | Details |
|---|---|---|
| 1 | JSON Format | Changed existing CPHA3 data format from fixed-width to JSON with UTF-8 encoding. Field mappings are one-to-one with CPHA3, but the structure is a FHIR JSON message. re minimum (i.e. tx number + date). It also includes cleaning up the values in network totals since most are not used (i.e. tax) |
| 2 | Original Version | As there will be mapping, add a field to the FHIR message header to convey the original message version --tbc |
| 3 | Enhanced Error Messages | Add standard error messages that can be used by adjudicators when there are parsing or routing errors (eg invalid BIN number). This means that the full claim processing response is not required. |
| 4 | Conformance | Add rules to enforce math on claim response. Numbers must add up correctly and balance. |
Parameter Resource (Anne - confirm against R4)
The custom Operations are defined in the "GET Totals and Details" section of this Implementation Guide (IG). This section provides detailed definitions of the Parameters resource that is used to send query criteria. The full FHIR specification for Operation defintions is found at the link HERE (insert link)
Following is a excerpt from the FHIR specification for the key search parameters that will be utilized.
| Parameter | Type | Description | Parameter Expression Structure | Example |
|---|---|---|---|---|
| number | Search parameter SHALL be a number (a whole number, or a decimal) | parameter =[comparator][number]_ length=27// equal to 27 length=27,28//equal to 27 or 28 length=lt27// less than 27 length=le27.6length=gt27 | ||
| date | Search parameter is on a date/time. | The date format is the standard XML format. | parameter=[comparator][date]birthdate=2010-10-01 | |
| String | parameters may contain spaces. | parameter=[value] name=john name=john,jack//john or jack token Search parameter on a coded element or identifier. May be used to search through the text, displayname, code and code/codesystem (for codes) andp label, system and key (for identifier). Its value is either a string or a pair of namespace and value, separated by a vertical bar, depending on the modifier used. |
parameter=[system][code] reference=www.url.com 123 reference | |
| Search parameter on a reference element | Allows identification of resources where a referenced resource matches the query ID. Not used in the current release |
parameter=[type]/[id] | requester=practitioner/123 |