In order to participate within the HIE as a point of care system, there are certain criteria that the POC must meet the following criteria:

Note: This is just a suggestion of how we could document these constraints. The following constraints represent actual behaviors on the SHR as it is currently implemented.

Communication Constraints (XDS) 

Generation of Clinical Documents (CDA)

Generic Constraints

The following constraints are placed on any point of care system (referred to as a consumer) which provides data to the SHR:

  • OPENSHR-01: Consumer systems SHALL track their unique implementation identity as an OID. This OID SHALL be unique for the instance of the consumer system and MAY be a subdivision of a particular deployment or clinic (for example: System A with OID=1.2.3.4.5 is in Clinic A with OID=1.2.3.4)

CDA Header Constraints

All Clinical Documents posted to the Shared Health Record are subject to the following additional constraints on their header (in addition to any underlying constraints placed on the document listed in the identified template)

  • OPENSHR-21: Documents SHALL indicate their conformance to a template by appending <templateId> elements to the Clinical Document identifying the templates to which the document conforms.
  • OPENSHR-22: Documents SHALL carry a globally unique document identifier represented as either the OID of the consumer system which produced them and an identifier, or a UUID
  • OPENSHR-23: Documents SHALL carry one and only one <recordTarget> element.
  • OPENSHR-24: Documents SHALL carry at least one <author> element, and SHALL only convey authorPerson (i.e. documents SHALL NOT use authorDevices)
    • OPENSHR-24.1: <author> elements SHALL carry a <representedOrganization>
  • OPENSHR-25: Documents SHALL carry one and only one <custodian> element which SHALL be populated with the implementation information for the clinic in which the document was generated
  • OPENSHR-26: Documents SHALL carry a <documentationOf> element which SHALL be populated with an <effectiveTime> having <low> represent the time of the earliest record conveyed in the document and <high> representing the most recent record in the document. For documents conveying a summary of an encounter (APHP, APL, etc.) this value represents the time span of the encounter which resulted in the document's being created.
  • OPENSHR-27: Documents which are being used to explicitly amend or replace the entire contents of another document (for example; in the case of erroneous data) SHALL carry a <relatedDocument> element.
    • OPENSHR-27.1: The <relatedDocument> element SHALL carry a <parentDocument> element having an <id> matching the unique identifier of the document to be replaced/amended.
    • OPENSHR-27.2: If a document is intended to replace the entire contents of a previous document (i.e. completely replace all data recorded within a previous document) then the <relatedDocument> SHALL carry a @typeCode of RPLC
    • OPENSHR-27.3: If a document is intended to amend the content of a previous document (i.e. add new data to a historical encounter) then the <relatedDocument> SHALL carry @typeCode of APND

CDA Entry Constraints 

All entries contained within a Clinical Document posted to the Shared Health Record are subject to the following additional constraints. These constraints are placed on document entries, in addition to any constraints listed in the entry's template:

  • OPENSHR-31: Entries within a document SHALL indicate their conformance to a template by appending <templateId> elements to the entry's clinical statement identifying the templates to which the entry conforms. Entries which do not carry a <templateId> SHALL NOT be imported by the SHR.
  • OPENSHR-31: Entries within a document SHALL contain an <id> element containing a globally unique identifier (OID + ID) pointing to the discrete data record which was used to generate the data. This <id> will represent a series of unchanging unique identifiers for the data and SHALL always be conveyed consistently across document instances. 
    • OPENSHR-31.1: The OID portion of the identifier SHALL contain an OID which identifies the source system and type of data (ex: If System A with OID=1.2.3.4.5 conveys an observation from it's observations table with primary key "4" it would produce id with OID=1.2.3.4.5.6 (System A + Observations) and ID="4").
    • OPENSHR-31.2: If the consumer is not the source of the information (i.e. it imported the information from another source such as another CDA), it SHALL NOT convey this information in the CDA. The SHR SHALL NOT process entries for which it already has recorded the unique id (i.e. the SHR will return an error if it encounters entries carrying an ID which it already has information). If the consumer wishes to update the data conveyed in the entry, it SHALL do this using the mechanism identified in OPENSHR-33.
  • OPENSHR-32: Consumer systems SHALL NOT convey entries within the clinical document for it does no possess discrete data (ex. do not produce allergy entries if no allergies exist in the source system). 
  • OPENSHR-33: All entries within a clinical document represent an amendment to existing data within the shared health record (i.e. all entries are considered new data), if a consumer wishes to convey that an entry is intended to replace existing data (ex: updating erroneous data) it SHALL indicate this by appending <reference> elements to the clinical statement.
    • OPENSHR-33.1: The <reference> element SHALL carry @typeCode of  RPLC indicating a replacement
    • OPENSHR-33.2: The <reference> element SHALL contain an <externalAct> element having an <id> element matching the unchanging global identifier (OID + ID) of the entry to be replaced.

 

  • No labels

This work is licensed under a Creative Commons Attribution 4.0 International License.