Shared Health Specification and Guide Version 5.0

0.1 Introduction and Scope

This message specification provides the foundation for messages that are shared. These messages are therefore defined in a shared space rather than being embedded and duplicated the message profiles in each product specification that utilizes these messages. This guide defines the message profiles, workflows and processes that stakeholders must adhere to in order to be compliant with these shared product offering.

0.1 Background

This Specification is based on the May 2016 FHIR specification. Note that the May 2016 FHIR publication (sometimes called FHIR 2.1) was an "interim" release of FHIR and is not the current official FHIR release. However, this specification is tied to that specific FHIR version. So when browsing links in the May 2016 FHIR spec, disregard the notice at the top of some pages that attempts to redirect you to the STU 3 or newer releases of FHIR. This specification will not work with any release other than the May 2016 release of FHIR.

Understanding of this implementation guide is contingent on understanding at least some parts of the base FHIR specification. The FHIR specification is highly linked to the Profiles and the user may move between the Shared Health specification and the core FHIR specification using links throughout the document. Shared Health implementation guide pages will have the Shared Health logo. All core FHIR pages will show the FHIR logo. This link will take you to the base FHIR site. FHIR Home is an external site.

0.1.1 Contact - Support

A point of contact will be provided to all registered partners. Any clarification or technical guidance will be arranged by your contact.

0.2 Business Scope

The following is a list of common services that are supported in this implementation guide.

• Acknowledgement/Error: The HTTP 2xx, 4xx, or 5xx is compliant with REST which FHIR uses as a base standard. This provides acknowledgement of receipt of the message from PrescribeIT® Switch and will indicate any detected issues with the transaction and appropriate details. The 'Acknowledgement/Error' response will reference all relevant identifiers from the submitted message.
• Registry Queries: These are queries to the Provider Registry to search for an organization (clinic, pharmacy, etc.) or practitioner (e.g. physician) to determine the identifiers for the target organization or individual as well as what services they are registered to support.
• Message Disposition Notification (901): This is an asynchronous rejection of a message. It indicates that an electronic delivery was not successful. Delivery may have been made by an alternate method.
• Clinician communication Recipient Asynchronous Reject: (997) A response from a recipient system indicating that a message was reject a secure communicaiton submission asynchronously
• Clinician communication Hub Asynchronous Rejection: (998) A response from a recipient system indicating an asynchronous rejection of a Clinician communication message by hub (due to parsing or processing error)
• Polling: There are a series of messages that support the polling and clearing of messages from PrescribeIT® Switch inbox.

0.2 Understanding FHIR

This guide and all derived implementation guides are based on the HL7 FHIR standard. Implementers who do not already have a background in FHIR are encouraged to familiarize themselves with some of the basic functioning of FHIR interfaces and how to read this specification. Recommended pages include:

• Developer's Overview
• Base Resource
• Domain Resource
• Extensibility
• Formats
• XML
• Datatypes
• RESTful API
• Search
• Messaging
• Downloads - Schemas, Code, Tools

Implementers should be familiar with XML and are strongly encouraged to make use of XML editing tools that provide schema validation capabilities such as XML Spy or Oxygen to aid in viewing and manipulating test and sample instances. As well, there is a set of FHIR tools available to support editing and validating instances. Implementers are encouraged to familiarize themselves with these tools.

FHIR has an active and supportive community. A summary of some of the support resources available can be found on the FHIR Support page.

This link will take you to the base FHIR site. FHIR Home This is an external site. Once you navigate to this site, you will no longer be in the Shared Health implementation guide.

0.2.1 Resources, Identifiers and References

FHIR organizes information as collections of "resources". Most of the time, each resource is treated as a stand-alone entity that can be created, updated, deleted and queried independently. Linkages between resources are handled using the Reference data type. Further information on how references work can be found here.

References can be contained, included in the message Bundle or left as remote references. This guide indicates which behavior is expected with an icon following the Reference data type and with a note in the data dictionary page of each profile. The icons are:

{c}	contained
{b}	bundled
{r}	remote

In general, this guide does not expect systems to persist and retain resource URIs to resolve references into the future. Therefore, in many cases the Reference Identifier extension is used. That extension allows a reference to be performed by "business identifier" - a combination of a system URI and a human-readable identifier rather than an URI. Implementation guides requiring persistence of resource URLs will document this explicitly.

0.2.2 Profiling

The Profiles within this specification provide all of the key information that is required by vendors to build conformant messages. This specification and all derived specifications build on top of the May 2016 snapshot of the base HL7 FHIR specification. The FHIR specification defines set of clinical and administrative resources that can be used to exchange healthcare related information, along with a single set of XML schemas to validate those instances. All FHIR conformant instances must validate against that one set of schemas. (The schemas may be found on the FHIR download page.)

Recognizing that needs of healthcare systems have significant variability, FHIR also defines a Profiling mechanism by which the standard resources can be constrained and/or extended to reflect the needs of a specific implementation space. The profiles and extensions (along with supplementary code systems and value sets) that are needed to support the Shared Health Service exchanges are found within and will detail the message structure, required data elements, vocabularies, data types and business rules that vendors must conform to. These artifacts are rendered in this specification as HTML pages for ease of reading and navigation. The specification also provides numerous examples to demonstrate what conformant instances might look like.

Profiles provide key details about the implementation including the following, each of which is described in more detail below:

• Supported vs Non-supported declarations
• Cardinality
• Value Sets
• Conformance and Usage Rules

Profiles are hierarchical, in that there is a base FHIR resource to which Profiles then build upon and apply constraints and extensions. The child level profiles contain the full set of constraints. Parent profiles are useful in developing the re-usable object and child profiles are necessary to develop a specific bundle, message header or other structure.

0.2.3 Data Specifications - Data Types

The messaging specification supports UTF-8 character encoding. This must be declared at the first line of every message.

0.2.4 Must Support and Non-Supported Elements

FHIR resources and data types define a number of "core" data elements that are commonly used in the implementer community. FHIR also supports the introduction of extension and modifier extension elements to meet needs that are more specific to a particular implementation space. This profile constrains the base specification, requiring the presence of certain elements and requiring that many more elements be Supported.

In the context of this implementation guide, Supported means that sending systems must be capable of populating those data elements with meaningful data and that, where appropriate, the data is under the control of the user. (For example, the user wouldn't necessarily choose the specific Coding.system url or type a specific code, but they should be able to choose the desired concept.) Receiving systems must be able to parse, store and appropriately display the element as a reasonable user would expect.

In the 'Grid View' tab, only supported elements are shown. In the 'Snapshot Table' tab, Supported elements will have a red-boxed 'S' while non-supported data elements will not have the red-boxed 'S' in the flag column. Non-supported data elements can be ignored.

0.2.5 Cardinality

Cardinalities are specified on all elements within a resource, including references to other resources. Cardinalities are also detailed within each data type. The hierarchical relationships must be considered when looking at cardinalities. For example if an element allows 0..10 repetitions and a child element allows 0..5 repetitions, the total number of potential child repetitions would be between 0 and 50.

0.2.6 Data Types

The data types that are used are shown in the Profiles, in the column entitled 'Type". This could be a base FHIR datatype, that is unaltered, or, where applicable, the datatype could be extended or constrained.

An example of a data type extension is the Shared Health Address, which has taken the base FHIR data type and constrained it to indicate which data elements are not in scope. (id, extension, use, text, district, period).

0.2.7 Value Sets (vocabulary/terminology)

Code values must use the defined Value/code sets. Within the Grid View the vocabulary set is provided as the 'Binding'. It is a hyper-link that will take you to the code set. Code values must use the defined Value/code sets. Within the Grid View the vocabulary set is provided as the 'Binding'. It is a hyper-link that will take you to the code set. Customized value sets are maintained by Canada Health Infoway. The hyper-link will take you to the Infoway site, where you will have to login, in order to get access to the Infoway Terminology Gateway. The Terminology Gateway is a web-based solution that enables the distribution and sharing of terminology concepts, subsets and concept maps, making them available for web browsing, download or real time query. Some of the Value Sets are a fixed list and linked specifically to a Message Specification version (version will be noted in the url). Other Value Sets will be updated periodically by Canada Health Infoway. For these, the Vendors should (through the Terminology Gateway) subscribe to notifications so they will be informed of the changes being made and can make the necessary modifications to support. (PrescriptionMedicinialProduct. PrescriptionDrugForm. PrescriptionRouteOfAdministration. PrescriptionAdministratoinSite. PrescriptionForUse.)

To get a view of all value sets used in a particular implementation guide, use the artifact list. Value sets are also identified within the Profiles with a link to the supported value set.

A value set may be comprised of multiple code sets. Codes are not necessarily unique within a value set, therefore when defining the system for a code, it must reflect the ‘code system url’ and not that of the value set. More information can be found here: FHIR Value Sets

0.2.8 Extensions

A key part of the FHIR profiling process is introducing additional data elements - extensions - that support information not defined as part of the standard resource. Extensions can appear within any data element, though they most commonly appear at the "root" level of a resource. (Extensions are sent inside the element they directly apply to.) Every extension will point to its "definition". A complete list of all extensions defined within an implementation guide can also be found in the artifact list.

Extensions must appear in an instance in the location where the referencing profile indicates they must appear (generally close to the top of the element after id, meta, contained and narrative and before everything else). The extension must include the URL that defines the extension. The order of extensions does not matter except for multiple repetitions of the same type of extension, in which case the extension definition will indicate whether order is relevant

0.2.8.1 Pre-adopted extensions

In a few places, this specification will make use of data elements that are defined as part of resources in future versions of the FHIR specification but which are not part of the May 2016 release of FHIR used as the basis for this publication. For these, a special FHIR extension syntax is used for the extension URL:

			      http://hl7.org/fhir/StructureDefinition/extension-[path of future FHIR element]
		    

For example http://hl7.org/fhir/StructureDfeinition/extension-Reference.identifier.

When the URL follows this format, it will not resolve to a web page (i.e. it will raise a 404 error if you click on it) because the FHIR specification does not officially publish these as extensions. However, the meaning of the extension can be found by finding the appropriate "current" version of the FHIR data type or resource based on the URL name. For an example of an extension like this, see the Reference Identifier extension.

0.3 Helpful FHIR Tools

There is a great deal of tooling available to support FHIR implementation. Further details on available FHIR tools, including tooling provided in the guides can be found here

0.4 Messaging Sequence

The following represents the pattern of delivery of messages.

1. The sender will post a message to PrescribeIT® Switch
2. PrescribeIT® Switch will acknowledge receipt and post in the receiver's inbox. If PrescribeIT® Switch is able to process the message successfully, the POST will be responded to with an HTTP 201 status indicating that the message has been successfully stored. If not, the status will be either a 4xx or 5xx series code and an OperationOutcome instance may be returned.
3. The receiver will poll their inbox on a scheduled basis and retrieve any messages.
4. The receiver must then clear their inbox of all of the retrieved messages.

In some cases, message transmissions will be successful, but delivery may not proceed as normal. In these cases, a 901 - Disposition Notification response message will be added to the sender's message queue to retrieve by polling.

In other cases, PrescribeIT® Switch may not detect any issues with a submitted message, but the receiving system may have an issue processing it. If this occurs, the receiving system must post an asynchronous rejection message. On occasion, PrescribeIT® Switch might notice an issue later in the process and need to send an asynchronous rejection message. The specific message returned will vary depending on what message is being responded to and what family of messages was being used, however all such rejection messages will have a message header that adheres to the Asynchronous Rejection Pattern. If a PoS is processing for multiple receiving systems, a separate asynchronous response must be generated (where applicable) for each system. If the asynchronous rejection message is initiated by PrescribeIT® Switch end point, then that signals that the message was not delivered to any potential recipients.

0.5 Security

For security requirements, refer to the domain-specific implementation guide.

0.5.1 Service Delivery Framework

All communication between endpoints and PrescribeIT® Switch or Provider Registry occurs over a secure TLS connection with mutual certificate validation.

EMR/Clinic and PMS/Pharmacy Access control

Only registered and compliant systems will be allowed to connect and exchange messages with PrescribeIT® Switch. As part of the enrollment and activation process, the Service Delivery Framework (SDF) will assign a unique ID and issue a PKI Cert to each connecting system.

PrescribeIT® Switch will then be configured with message routing information consisting of the CPRID of the Clinic, the SDF assigned system ID and the Vendor assigned Application Instance Id.

The application instance will be linked to a specific version of a vendor application allowing for Conformance tracking and enforcement.

PrescribeIT® Switch will perform access control using a combined set of attributes:

• System Identity
• Registered System
• Conformance status of the Vendor Application
• Business identity
• Clinic or Pharmacy CPRID

0.5.2 Authentication

Our services require two factor authentication process for clinicians. First factor authentication is the Vendors 'password based login' process. The second level factor authentication - "Secure Token Service (STS)" will be satisfied using Secure Token Service (STS).

The second factor credentials for each registered practitioner will be stored in the Provider Registry. The credentials will consist of the channel and associated user name. The currently supported channels are

• One Time Password (OTP) via SMS
  • The password will be generated on demand ("requestOTP" operation on the STS) and sent directly to the user via SMS.
  • The "username" for this channel is simply the mobile phone number

Additional channels such as OTP soft tokens or mobile based challenge response authenticators may be added after launch.

Example value for the 2FA credentials - "SMS:4165551212" NOTE: the EMR does not have any knowledge of the 2FA credentials stored in the Provider Registry.

0.5.3 Second Factor Authentication (2FA) - Secure Token Service (STS)

Obtaining a One Time Password (OTP)

If the user is configured for OTP via SMS the EMR will contact the STS and request an OTP be sent to the user. This operation may be triggered by an explicit user action such as clicking on a button in the EMR or can be part of the login sequence.

Upon receiving the SMS the physician must enter the OTP in an EMR user interface that will act as a trigger to the EMR to send a request to the STS to obtain an authentication token. The STS will verify the OTP in the request by invoking the OTP component and if valid will issue an authentication token for the physician that is valid for a predefined amount of time, currently eight hours. All subsequent interactions between the EMR and PrescribeIT® Switch must contain the previously obtained authentication token.

Within your Vendor Implementation package, the specifications for RequestOTP, RequestToken, RequestMessageToInbox, GetMessageFromInbox, and AcknowledgeMessage can be accessed from the API Summary.

0.6 Conformance Process

0.6.1 Overview

All software vendors must comply with the associated message specifications and all conformance rules provided in the implementation package.

The result of a successful conformance process is that a vendor application will be certified for compliance with the Service. The vendor can then distribute the certified software to their client base and who can begin to use the service. Once certified, the solution is considered to be compliant with within the Service. There is no requirement for the vendors to recertify as the Service expands into include other new pharmacy and EMR software solutions or provinces.

The conformance process will focus on the ability of the vendor’s application to successfully create and send interactions and consume responses. The conformance process is essential in order to ensure the following:

• All the standards and technical specifications are properly implemented
• All systems are properly interpreting data
• Accuracy of data
• Minimal error handling and troubleshooting once in production
• Messaging is consistent across implementations.

Recertification may be required if the Vendor is making changes to their software. The Services Conformance team must be consulted for evaluation of potential impacts and confirmation if recertification is required. As implementation guides expand/change the messaging specifications, Vendors will be expected to adopt the changes within a defined period of time.

0.6.2 Conformance and Usage rules

Within the Profile – Grid View (or Detailed Description view), conformance rules for the data elements are stated. Conformance rules are mandatory and will be validated through the Vendor Conformance process. These rules describe the expected behaviour of the sending applications to populate to messages, as well as rules pertaining to the receiving applications.

The following terms will be used in the definition of the rules;.

• ‘Must’, ‘Shall’, ‘Required’, ‘Minimum’, or ‘Mandatory’ indicate a mandatory requirement.
• ‘May’, ‘Should’, ‘Recommended’, ‘Optional’, or ‘Suggested’ indicate a functional ability that, while not required by a minimum implementation, should be considered.

NOTE: These rules are available in the downloadable excel spreadsheets.

0.6.3 Conformance Program

Vendor Conformance testing ensures successful integration and compliance to the particular service. The testing to be performed will evaluate all aspects of the service’s functionality available within software applications.

In order to demonstrate compliance with the Service Requirements; Vendors will be asked to complete a set of Test Scenarios provided by the Conformance team.

0.6.4 Vendor Implementation Conformance Profiles

Implementation Conformance Profiles (ICP’s) are used as the basis for the conformance testing coverage. The ICP templates will be created by the Conformance team. The ICP’s are built against all business rules, terminology, data types, data element scope, technical rules and Interactions/messages documented in the VIG (Specification). The ICP identifies what type of business they are (PMS vs EMR), what interactions/messages they support and any special considerations to be noted.

The scope of the conformance testing process includes the following:

• Communication level (automatically tested)
• Application level testing
• Message level testing

The vendor’s application is reviewed and tested to ensure that vendors are compliant with all of the following:

0.6.5 Conformance Test Approach

The conformance process consists of three stages. During the three stages, the Conformance team will be available to answer any conformance related questions based on the agreed communication protocol. Vendors will be required to make their technical and conformance team readily available to the Conformance Team.

The three stages of conformance are the following:

• Stage 1 – Informal Conformance – Vendor software Integration and Self-Testing
• Stage 2 – Formal Conformance/Certification – Vendor software conformance evaluation
• Stage 3 – Conformance Re-Certification

0.6.5.1 Stage 1 – Informal Conformance

The purpose of the first stage is to enable vendors to validate the compliancy of their software and fix any issues found; prior to the formal conformance stage. At this stage a Vendor must ensure that they can construct, send and receive Service solution compliant messages.

A Vendor must execute the Test Scenarios provided in the conformance kit pertaining to their line of business and Interaction/message coverage stated in their Vendor Implementation Conformance Profile (ICP’s). In order to ensure that the request messages are properly created by the EMR and PMS systems and that the response information is processed and displayed as expected, vendors will be asked to provide the Conformance team with screenshots, printouts and other supporting artifacts. These artifacts will then be analyzed by the Conformance team to ensure that the expected result is attained.

Prior to integrating to the service, an EMR and PMS vendor will have the opportunity to validate their messages with the FHIR Validator Tool kit (consisting of the stock open-source FHIR command line validator and the service-specific FHIR profile).

Vendors will also be provided with a SOAPUI project that will act as their Sender/Receiver partner. They will be able to create the appropriate messages they need to consume.

Entry Criteria

• When Vendors have tested their application and are ready to integrate to the conformance environment and start the Informal Conformance Testing
• Vendor has contacted the Conformance team to advise that they are ready to begin stage 1 of conformance testing
• Delivery of 1 message (all encompassing) so that it can be evaluated for readiness
• Conformance team has provided the vendor with their starter supply of test data and test scripts

Exit Criteria

• All Test Scenarios have passed and have attained expected results
• The Conformance team has analyzed the artifacts and has found no issues

0.6.5.2 Stage 2 – Formal Conformance/Certification Testing

The purpose of this stage is to certify that an EMR or PMS software is complaint and that each interaction fulfils the service requirements and generates output as expected. Since work has been done upfront by the Vendors; the duration of this stage is expected to be 6-8 weeks.

• The Conformance team will instruct and observe the transmission of transactions to/from PrescribeIT® Switch. Each transaction will be verified against a set of expected results. Where applicable, the conformance team will also examine the local system to ensure that data is being correctly sent, received and stored locally. The examinations may be performed; on submitted artifacts, onsite, via a WebEx or a Live meeting application.
• When the evaluation has been successfully completed, a vendor’s software will be considered “certified. A certification will be accordingly issued outlining details including, but not limited to, software version, date, file size(s) and Interactions supported.
• If an application fails, the evaluation may be halted. The conformance team may depart and a new evaluation will be scheduled.

A version number must uniquely identify each iteration of a local software application that has achieved a compliant status. The version number must be provided within the message structure as defined in the appropriate standards.

The local software version number must increment when a new release is issued.

Random audits will be performed to ensure that the version number being transmitted correlates with the version of the application that has been approved for use.

In order for a vendor’s application to be considered “certified”, an EMR or PMS vendor will need to have successfully completed this stage of the conformance testing process.

Entry Criteria

• Completion of Stage 1: Vendors will make a decision to move to this phase in consultation with the Conformance Team

Exit Criteria

• Vendor must provide proof of compliance through successful execution of test cases deemed to be part of the conformance test suite for a particular Vendor
• All defects found must be fixed and verified in subsequent conformance cycles unless approved by the Conformance team.

Certification

• Once the exit criteria are attained, a vendor’s software will become certified. Canada Health Infoway will register the vendor’s application version as certified and able to interact with the PrescribeIT®.

0.6.5.3 Stage 3 – Conformance Re-Certification

The purpose of this stage is to ensure that when changes are made; either to an EMR or PMS software or to the Service; that the entire eco system continues to function as required. Based on the ICP (Implementation Conformance Profiles); End-to-End Conformance Regression Tests will be identified by the Conformance Team and will need to executed. Some changes may identify new interactions/messages being supported thus new tests may be added and those too will need to be executed.

All EMR and PMS accessing the Service must agree to the following release management requirements:

• Written notification to the Conformance taem describing changes or upgrades to the local software is required before a Software Vendor may be release the changes to production
• An Application may be exempted from a conformance re-certification at the discretion of the PrescribeIT® Conformance Team; if it can be determined that all functionality related to Service has not been affected in any way
• When a new version of the Service is released, all EMR and PMS accessing the Service will be made aware of the upcoming changes.
• Vendors will be notified of upcoming changes so that vendors get time to prepare and modify their software in order to conform to the new requirements. When a new version of the Service is released and they deem there is no needed to perform conformance re-certification, it will be recommended that vendors still run some tests.
• Again an EMR and/or a PMS Application may be exempted from a conformance re-certification at the discretion of the Conformance Team if it can be determined that the changes made to Service have not affected the Messaging functionality in any way.

Entry Criteria

• A new Version of an EMR or PMS Software is to be released and Vendor has provided details of changes; and/or
• A new Version of Service is released, Vendors have been advised of changes
• Conformance Re-Certification Tests have been identified

Exit Criteria

• An Application is Exempt from Conformance Re-certification; and/or
• Vendor must provide proof of compliance through successful execution of test cases deemed to be part of the conformance re-certification test suite for a particular Vendor
• All defects found must be fixed and verified in subsequent conformance cycles unless approved by the Conformance team.

Re-Certification

• Once the exit criteria are attained, a vendor’s software will become re-certified. Canada Health Infoway will register the vendor’s application version as certified and able to interact with the PrescribeIT®.

0.6.5.4 Conformance Environment

The Conformance Test environment will be used for all three stages in the vendor conformance testing process. This environment will be able to handle multiple vendors testing at the same time. Comprehensive environment support is provided by the Technical Architecture and Development teams through the entire process of conformance testing.

During any of the conformance testing process, testing EMR and PMS vendors may be testing with simulators, which are available in the test environment. PrescribeIT® Switch will receive requests, direct them accordingly and provide the appropriate responses. See below:

0.6.5.5 Conformance Test Data

The Test Data to be used for Conformance testing will be set up prior to conducting conformance testing with vendors. During any of the Conformance Testing Stages; a Vendor must not submit any real patient’s person information or patient’s health information. The database may be reset after each round of testing. (Vendor may not necessarily be using the same set of data twice in a row). The test case suite will also be updated with the test data that must be used during this phase of conformance testing. Test Data will be managed by the Conformance team’s Technical Analyst. This will be published in conjunction with the suite of test cases.

0.6.5.6 Conformance Defects

The Excel Defect Layout spreadsheet will be used for Conformance testing to track and communicate all of the identified defects across the teams involved in conformance test. It is proven that this is the most economical way of handling and resolving defects considering the size and number of stakeholders involved.

During conformance testing, if an EMR or PMS application doesn’t meet the conformance certification/re-certification criteria and if the actual results are not compliant with expected results described in test cases, a defect must be created. The severity and priority of a defect depends on the nature of the problem detected by the technical analyst. For setting defect severity, the following criteria will be used:

• Severity Level 1: Critical (Urgent) This severity level is assigned when an error causes a “stop work” situation, where there is no functional work-around and the conformance testing process is halted. Since this type of fault is a critical error, problem resolution must be immediate; the system cannot be certified.
• Severity Level 2: Functional (High) This severity level is assigned when an error restricts operation of an important function by impacting specific business functions, procedures, controls or public image. Testing may be interrupted for this particular function, but other testing can continue. The resolution of this level of error is a high priority.
• Severity Level 3: Deficient (Medium) This severity level is assigned when all major functions of the system continue to operate, but the defect has impacted the quality of one or more functions of vendor application. The resolution of this level of error should be done within the release depending on an agreement between vendor and the conformance team.
• Severity Level 4: (Low) These errors represent minor problems or cosmetic errors and do not affect the overall operation of the application. The vendor system can be certified and fixes may be instituted in a future release, patch or upgrade.

A list of all outstanding defects will be issued prior every defect review meeting.

Defect Template

The following template will be filled for each defect found:

Issue Resolution Process

On occasion there may be a difference of opinion on how the vendor has interpreted the specification or any of the stated conformance rules. When this situation does occur, the Conformance team will bring the matter to the attention of the ‘messaging group’. This group consists of multiple roles, and its objective is to come to consensus on resolution of the issue.

1. Conformance Team opens a defect in HP-QC and assigns the defect to the appropriate Developer for resolution.

   PrescribeIT® Switch BSA is 'informed' of all Defects and receives a copy.

2. Developer will evaluate and assess the Defect

   PrescribeIT® Switch BSA also evaluates and adds comments or provide clarification, as needed

3. There is a decision point on whether or not there is an issue that requires consultation with a broader audience. Conformance Team lead and PrescribeIT® Switch BSA will make this call.

4. Meeting is established with appropriate technical representation from impacted teams, BSA + Conformance Team partners.

   Options are presented and conclusions on the resolutions are determined.

5. The resolution is presented to the business messaging team for consensus. This is typically done by the Messaging Architect or PrescribeIT® Switch BSA.

6. Once consensus is obtained, technical team, will document outcomes and specific impacts and actions that are required.

7. Another decision point is required. If there is an impact to timelines, costs, etc, the outcomes and actions are brought to the attention of the Sr Management team.

8. Sr Management provides their input and authorizes the outcomes.

9. Communication of the final resolution, outcomes and actions is presented to all partners. Development + Conformance Team, Business and Product. NOTE: This may have an impact to external partners as well and communication to them must be managed based on the established communication protocols in place with them.

   NOTE: This may result in a specification change or further clarity in conformance rules within the Specification.

10. The HP-QC Defect is updated with the outcomes and Conformance lead will continue to manage the process of implementation and eventually the passing of the test script as being compliant.

0.7 General Conformance Rules and Usage Notes

The following is a list of conformance rules that must be adhered to. Adherence will be validated through the Conformance program. The rules listed here are either general for the program or are associated with specific service Tasks.

0.8 Message Interactions - 901

The following shows the content that would actually go over the wire for a message instance

			
POST https://site2.api.sharedhealth.exchange/rest/v1/preconf/THP/mailbox_vs1/Bundle HTTP/1.1
Accept: application/XML+fhir
Content-Type: application/XML+fhir;charset=utf-8

<?xml version="1.0" encoding="UTF-8"?>
<Bundle xmlns="http://hl7.org/fhir">
...
</Bundle>
      
		

The response would look like this:

			
HTTP 201 Created
Date: Sat, 09 Feb 2013 16:09:50 GMT
Last-Modified: Sat, 02 Feb 2013 12:02:47 GMT
ETag: W/"1"
Content-Type: application/json+fhir;charset=utf-8
Content-Length: [number of characters of payload]
Content-Location: https://site2.api.sharedhealth.exchange/rest/v1/preconf/THP/mailbox_vs1/Bundle/[some sequential id]/_history/1
      
		

or something like this:

			
HTTP 400 Bad Request
Date: Sat, 09 Feb 2013 16:09:50 GMT
Content-Type: application/json+fhir;charset=utf-8
Content-Length: [number of characters of payload]

<?xml version="1.0" encoding="UTF-8"?>
<OperationOutcome xmlns="http://hl7.org/fhir">
...
</OperationOutcome>
      
		

0.9 Queries and Operations

Guidance on polling and provider registry queries is found on a separate page.