CollabKare Conformance Requirements

This section outlines conformance requirements for the CollabKare and Client applications, identifying the specific profiles that need to be supported, the specific RESTful operations that need to be supported, and the search parameters that need to be supported.

Conformance requirements for the CollabKare

Source Resource: XML/JSON

  1. FHIR Version: 4.0.1
  2. Supported formats: xml, json
  3. Published: Draft

This section describes the expected capabilities of the CollabKare actor that is responsible for providing responses to the queries submitted by the CollabKare Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by CollabKare are defined.

Behavior

Description:

The CollabKare responder SHALL:

  1. Support the CollabKare resource profiles.
  2. Implement the RESTful behavior according to the FHIR specification.
  3. Return the following response classes:
    • (Status 200): successful operation
    • (Status 400): invalid parameter
    • (Status 401/4xx): unauthorized request
    • (Status 403): insufficient scope
    • (Status 404): unknown resource
    • (Status 410): deleted resource.
  4. Support json resource formats for all CollabKare interactions.
  5. Declare a CapabilityStatement identifying the list of profiles, operations, search parameter supported.

The CollabKare responder SHOULD:

  1. Support xml resource formats for all CollabKare interactions.
  2. Identify the CollabKare profiles supported as part of the FHIR meta.profile attribute for each instance.

Security:

The CollabKares responder SHALL:

  1. Implement the security requirements documented in the this IG.
  2. A server has ensured that every API request includes a valid Authorization token, supplied via: Authorization: Bearer {server-specific-token-here}
  3. A server has rejected any unauthorized requests by returning an HTTP 401 Unauthorized response code.

Profile Interaction Summary:

  1. All servers SHALL make available the read and search interactions for the Profiles the server chooses to support.
  2. All servers SHOULD make available the vread and history-instance interactions for the Profiles the server chooses to support.

Summary of CollabKare search criteria:

Specific server search capabilities are under analysis.

Resource Details:

Supported Profiles: Specific profile support requirements are under analysis.

Server side Operations

A server SHALL be capable of returning based on Snomed-CT code

GET [base]/Observation?patient=[id]&code=Snomed-CT code

  1. A server SHALL be capable of returning a patient Obstetric history

    GET [base]/Observation?patient=[id]&code=248983002

  2. A server SHALL be capable of returning a patient PregnancyObservation

    GET [base]/Observation?patient=[id]&code=289908002

  3. A server SHALL be capable of returning a patient Gynecological history (observable entity)

    GET [base]/Observation?patient=[id]&code=267011001

  4. A server SHALL be capable of returning a patient BreastObservation

    GET [base]/Observation?patient=[id]&code=76752008

  5. A server SHALL be capable of returning a patient MensuralCycleObservation

    GET [base]/Observation?patient=[id]&code=248960000

  6. A server SHALL be capable of returning a patient OtherObservation

    GET [base]/Observation?patient=[id]&code=74964007

  7. A server SHALL be capable of returning a patient PapSmearObservation

    GET [base]/Observation?patient=[id]&code=90226004

  8. A server SHALL Creates a new Observation resource.

    POST [base]/Observation

  9. A server SHALL Updates Observation resource.

    PUT [base]/Observation/[id]

  10. A server SHALL Deletes a single Observation based on the ID supplied

    DELETE [base]/Observation/[id]

Workflow

The workflow module focuses on the coordination of activities within and across systems. Workflow manifests in many places in the healthcare environment:

  • We are creating a file which will monitor the process of scenarios(ex: Lab, Medication, Appointment, etc) that are moving to Patient through FHIR server. To document the steps that are happening through out the process and their status.
  • Creating a lab order, drug prescription, or other clinical order or an insurance claim, enrollment request, Appointment or similar administrative request and asking for it to be actioned by a specific organization or practitioner
  • Negotiating a fulfillment process, such as requesting further information before accepting a claim or referral or proposing an alternative therapy when processing an order
  • Letting an ordering physician know what the current progress is in fulfilling an order (e.g. blood has been drawn, sample is being processed, preliminary results are in, etc.)

Messaging System

The messaging system exists to support context-based routing of messages. In app Notifications : We are creating a separate protocol through web sockets for messaging. For Example, If one from other device updates the patient related information, then it will display a message regarding the patient related updates in app.

CDS Hooks

Clinical Decision Support System will work by taking CDS Hooks. In client App, CDS Hooks fhir up the CDS Services. By using CDS Hooks, the third party service will work.

User activity inside the EHR triggers CDS hooks in real-time.

  • patient-view: when opening a new patient record.
  • medication-prescribe: on authoring a new prescription.
  • order-review: on viewing pending orders for approval.

A CDS Hooks scenario typically includes two main actors: an EHR and a CDS Service. The interaction for the patient-view hook is as follows.

  1. EHR Triggers the patient-view CDS hook and invokes a remote service.
  2. CDS service executes it’s own rules,leveraging FHIR data as needed.
  3. Returns CDS card which is rendered and displayed by EHR.

Subscription

The subscription resource is used to define a push based subscription from a server to another system. A notification for a limited time, giving the updates details. We are using the following subscription types.

1. REST Hook: In this rest-hook subscription type If the subscription requests that the whole resource is included, the URL is interpreted as the service base. Criteria is important in the rest-hook type subscription. Based on criteria it will return the update information. If the end time will expires then the status will return Off. Again we need to reset the date and change the status to active.

2. Email: In this email type subscription, A notification is sent to the nominated email address. Email type subscription will have payload. we will mention some description in this payload. criteria is important in the email type subscription.

3. WebSocket: websocket type subscription A message is sent to the designated URI. web mean network socket mean connection websocket mean network connection. this websocket mainly used to communicate with the client device without need of communication Once a subscription is created, any newly created or updated resources will be returned. In this process, it will return only one resource type update information. But we implemented one to many resource type information. Criteria is important in the websocket type subscription. Suppose, patient have lot of information means this includes multiple resource types. when we use this websocket type subscription, it will return all the resource types update information.

FHIRPath

FHIRPath is a path-based navigation and extraction language, somewhat like XPath. Operations are expressed in terms of the logical content of hierarchical data models, and support traversal, selection and filtering of data.

  • FHIRPath uses a tree model that abstracts away the actual underlying datamodel of the data being queried.
  • Another advantage of specifying FHIRPath as a subset of CQL is that it reduces the number of competing standards in the space. If FHIRPath and CQL continue down two different paths, implementers who work with both will likely be frustrated by how similar, yet different, they are. On the other hand, if FHIRPath is a subset of CQL, implementers who already know CQL will automatically know FHIRPath — and implementers who already know FHIRPath will be well on their way to learning CQL. This seems a clear opportunity to potentially reduce the unnecessary proliferation of standards.

Use of FHIRPath in Clinical Quality Language (CQL)

Clinical Quality Language is being extended to use FHIRPath as its core path language, in much the same way that XQuery uses XPath to represent paths within queries. When a path expression involves an element with multiple cardinality, the expression is considered short-hand for an equivalent query invocation.

For example:

  • Patient.telecom.use Patient can have multiple telecom entries. It can be expressed in the hierarchical form.
  • Patient.name.given In this case, given a patient with multiple names, each of which has multiple givens, this will return a single list containing all the given names in all the names.
  • If we want some sort of Analytics like formulas we need to use the CQL.