0.0.1 - CI Build

SequoiaProjectHealthcareDirectoryImplementationGuideSTU3 - Local Development build (v0.0.1). See the Directory of published versions

Directory Document Semantics

Previous Page - Web Application (GUI)

Organizational ID and Identifier

Background

All FHIR resources have special considerations in terms of their id and identifier data elements. The following sections discuss those considerations and how the Sequoia Healthcare Directory has implemented them.

Organizational id

Reference: https://www.hl7.org/fhir/resource.html#id Directory Organization.id values follow the following FHIR rules:

  1. Each Organization.id is assigned by the server storing the resource.
  2. Resources always have organization.ids except for the special case of creation.
  3. The Organization.id is unique for all organization-type resources on the directory.
  4. The Organization.id value never changes. For the Sequoia Healthcare directory, the above rules are implemented in the following ways:
  5. The Organization.id is that Organizations IHE XCPD HomeCommunityID value. 1. CONF: Clients MUST use the Organization’s IHE XCPD HomeCommunityID value as the Organization.id value.
  6. The Organization.id must be globally unique within the directory. 1. CONF: Clients MUST NOT use the same Organization.id for more than one Organization entry in a directory instance.
  7. Only the dotted numeric format OID value is to be stored in the organization.id field. 1. CONF: Clients MUST use the OID dotted decimal numeric format for Organzation.id values. Example: An example of a valid organization.id value is Organization.id=2.16.840.1.113883.3.1490 Organization.id values are preserved across server instances, they are preserved when data is imported from a properly formatted Excel file, and they are preserved when organizations are created and updated via a RESTful operation. This constraint is also observed when Sequoia Healthcare directories are deployed in a master/slave server cluster. Finally, the organization.id value is also be preserved when using any combination of these scenarios.

Organizational identifier

Organizational.identifier values follow the IHE HomeCommunityID format of urn:oid:1.2.3.4.5. The OID value proper will be used in the Sequoia Healthcare Directory as the Organizational.id value. Conf: Organizational.identifier values must use the format of urn:oid:number[.number]+

Value Sets

Bundle/entry/resource/Organization/contained/Endpoint/connectionType

Code Display Definition
ihe-xcpd IHE XCPD IHE Cross Community Access Profile (XCA) - http://wiki.ihe.net/index.php/Cross-Community_Access
ihe-xca IHE XCA Some operations such as create only support xml as detailed elsewhere in this document.
ihe-xdr IHE XDR IHE Cross-Enterprise Document Reliable Exchange (XDR) - http://wiki.ihe.net/index.php/Cross-enterprise_Document_Reliable_Interchange
ihe-xds IHE XDS IHE Cross-Enterprise Document Sharing (XDS) - http://wiki.ihe.net/index.php/Cross-Enterprise_Document_Sharing
ihe-iid IHE IID IHE Invoke Image Display (IID) - http://wiki.ihe.net/index.php/Invoke_Image_Display
dicom-wado-rs DICOM WADO-RS DICOMweb RESTful Image Retrieve - http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_6.5.html
dicom-qido-rs DICOM QIDO-RS DICOMweb RESTful Image query - http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_6.7.html
dicom-stow-rs DICOM STOW-RS DICOMweb RESTful image sending and storage - http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_6.6.html
dicom-wado-uri DICOM WADO-URI DICOMweb Image Retrieve - http://dicom.nema.org/dicom/2013/output/chtml/part18/sect_6.3.html
hl7-fhir-rest HL7 FHIR Interact with the server interface using FHIR's RESTful interface. For details on its version/capabilities you should connect the value in Endpoint.address and retrieve the FHIR CapabilityStatement.
hl7-fhir-msg HL7 FHIR Messaging Use the servers FHIR Messaging interface. Details can be found on the messaging.html page in the FHIR Specification. The FHIR server's base address is specified in the Endpoint.address property.
hl7v2-mllp HL7 v2 MLLP HL7v2 messages over an LLP TCP connection
secure-email Secure email Email delivery using a digital certificate to encrypt the content using the public key, receiver must have the private key to decrypt the content
direct-project Direct Project Direct Project information http://build.fhir.org/valueset-endpoint-connection-type.html

Bundle/entry/resource/Organization/contained/Endpoint/connectionType

http://build.fhir.org/valueset-endpoint-status.html

</td>
Code Display Definition
active Active This endpoint is expected to be active and can be used
suspended Suspended This endpoint is temporarily unavailable
error Error This endpoint has exceeded connectivity thresholds and is considered in an error state and should no longer be attempted to connect to until corrective action is taken
off Off This endpoint is no longer to be used
entered-in-error Entered in error This instance should not have been part of this patient's medical record.
test Test This endpoint is not intended for production usage.

Bundle/entry/resource/Organization/contained/Endpoint/payloadType

http://build.fhir.org/valueset-endpoint-payload-type.html This value set includes codes from the following code systems: Include all codes defined in http://hl7.org/fhir/endpoint-payload-type Include these codes as defined in urn:oid:1.3.6.1.4.1.19376.1.2.3

Code Display
:ihe:pcc:handp:2008 History and Physical Specification
:ihe:pcc:xphr:2007 HL7 CCD Document
:ihe:pcc:aps:2007 IHE Antepartum Summary
:ihe:pcc:xds-ms:2007 XDS Medical Summaries
:ihe:pcc:xphr:2007 Personal Health Records
:ihe:pcc:edr:2007 Emergency Department Referral (EDR)
:ihe:pcc:edes:2007 Emergency Department Encounter Summary (EDES)
:ihe:pcc:apr:handp:2008 Antepartum Record (APR) - History and Physical
:ihe:pcc:apr:lab:2008 Antepartum Record (APR) - Laboratory
:ihe:pcc:apr:edu:2008 Antepartum Record (APR) - Education
:ihe:pcc:irc:2008 Immunization Registry Content (IRC)
:ihe:pcc:crc:2008 Cancer Registry Content (CRC)
:ihe:pcc:cm:2008 Care Management (CM)
:ihe:pcc:ic:2009 Immunization Content (IC)
:ihe:pcc:tn:2007 PCC TN
:ihe:pcc:nn:2007 PCC NN
:ihe:pcc:ctn:2007 PCC CTN
:ihe:pcc:edpn:2007 PCC EDPN
:ihe:pcc:hp:2008 PCC HP
:ihe:pcc:ldhp:2009 PCC LDHP
:ihe:pcc:lds:2009 PCC LDS
:ihe:pcc:mds:2009 PCC MDS
:ihe:pcc:nds:2010 PCC NDS
:ihe:pcc:ppvs:2010 PCC PPVS
:ihe:pcc:trs:2011 PCC TRS
:ihe:pcc:ets:2011 PCC ETS
:ihe:pcc:its:2011 PCC ITS
:ihe:iti:bppc:2007 Basic Patient Privacy Consents
:ihe:iti:bppc-sd:2007 Basic Patient Privacy Consents with Scanned Document
:ihe:iti:xdw:2011:workflowDoc XDW Workflow Document
:ihe:iti:dsg:detached:2014 DSG Detached Document
:ihe:iti:dsg:enveloping:2014 DSG Enveloping Document
:ihe:iti:xds-sd:pdf:2008 PDF embedded in CDA per XDS-SD profile
:ihe:iti:xds-sd:text:2008 Text embedded in CDA per XDS-SD profile
:ihe:lab:xd-lab:2008 CDA Laboratory Report
:ihe:rad:TEXT Radiology XDS-I Text
:ihe:rad:PDF Radiology XDS-I PDF
:ihe:rad:CDA:ImagingReportStructuredHeadings:2013 Radiology XDS-I Structured CDA
:ihe:card:imaging:2011 Cardiac Imaging Report
:ihe:card:CRC:2012 Cardiology CRC
:ihe:card:EPRC-IE:2014 Cardiology EPRC-IE
:ihe:dent:TEXT Dental Text
:ihe:dent:PDF Dental PDF
:ihe:dent:CDA:ImagingReportStructuredHeadings:2013 Dental CDA
:ihe:pat:apsr:all:2010 Anatomic Pathology Structured Report All
:ihe:pat:apsr:cancer:all:2010 Anatomic Pathology Structured Report Cancer All
:ihe:pat:apsr:cancer:breast:2010 Anatomic Pathology Structured Report Cancer Breast
:ihe:pat:apsr:cancer:colon:2010 Anatomic Pathology Structured Report Cancer Colon
:ihe:pat:apsr:cancer:prostate:2010 Anatomic Pathology Structured Report Cancer Prostate
:ihe:pat:apsr:cancer:thyroid:2010 Anatomic Pathology Structured Report Cancer Thyroid
:ihe:pat:apsr:cancer:lung:2010 Anatomic Pathology Structured Report Cancer Lung
:ihe:pat:apsr:cancer:skin:2010 Anatomic Pathology Structured Report Cancer Skin
:ihe:pat:apsr:cancer:kidney:2010 Anatomic Pathology Structured Report Cancer Kidney
:ihe:pat:apsr:cancer:cervix:2010 Anatomic Pathology Structured Report Cancer Cervix
:ihe:pat:apsr:cancer:endometrium:2010 Anatomic Pathology Structured Report Cancer Endometrium
:ihe:pat:apsr:cancer:ovary:2010 Anatomic Pathology Structured Report Cancer Ovary
:ihe:pat:apsr:cancer:esophagus: 2010 Anatomic Pathology Structured Report Cancer Esophagus
:ihe:pat:apsr:cancer:stomach: 2010 Anatomic Pathology Structured Report Cancer Stomach
:ihe:pat:apsr:cancer:liver:2010 Anatomic Pathology Structured Report Cancer Liver
:ihe:pat:apsr:cancer:pancreas: 2010 Anatomic Pathology Structured Report Cancer Pancreas
:ihe:pat:apsr:cancer:testis:2010 Anatomic Pathology Structured Report Cancer Testis
:ihe:pat:apsr:cancer:urinary_bladder:2010 Anatomic Pathology Structured Report Cancer Urinary Bladder
:ihe:pat:apsr:cancer:lip_oral_cavity:2010 Anatomic Pathology Structured Report Cancer Lip Oral Cavity
:ihe:pat:apsr:cancer:pharynx:2010 Anatomic Pathology Structured Report Cancer Pharynx
:ihe:pat:apsr:cancer:salivary_gland:2010 Anatomic Pathology Structured Report Cancer Salivary Gland
:ihe:pat:apsr:cancer:larynx:2010 Anatomic Pathology Structured Report Cancer Larynx
:ihe:pharm:pre:2010 Pharmacy Pre
:ihe:pharm:padv:2010 Pharmacy PADV
:ihe:pharm:dis:2010 Pharmacy DIS
:ihe:pharm:pml:2013 Pharmacy PML
:hl7-org:sdwg:ccda-structuredBody:1.1 For documents following C-CDA constraints using a structured body.
:hl7-org:sdwg:ccda-nonXMLBody:1.1 For documents following C-CDA constraints using a non structured body.

Carequality Policy Assertions

Proposed addition: We propose adding a new EndPoint data element indicating if the described Initiating Gateway supports sending policy assertions or not. If the Initiating Gateway supports sending the Carequality policy assertion statements (as per the Carequality Implementation Guide), then the Bundle/entry/resource/Organization/contained/Endpoint/payloadType Healthcare Directory will contain one or more of the following values: This value is mandatory and may not be left empty or missing in the Healthcare Directory.

Code Display Definition
InitiateSendAssertNone The Initiating Gateway does not send Carequality policy assertions. The Initiating Gateway will not send Carequality assertions and will silently fail to parse responses with Carequality Policy assertion data.
InitiateSendAssertSome The Initiating Gateway can send Carequality policy assertions, but may not send an assertion in all cases. An assertion will be sent if the Initiating Gateway determines that it is appropriate. In some cases the assertion will not be sent, such as if the Initiating Gateway does not have a policy assertion.
InitiateSendAssertAll The Initiating Gateway can send Carequality policy assertions, and will send an assertion in all cases. A populated assertion data element will be sent if the Initiating Gateway determines that it is appropriate. In some cases the assertion cannot be populated and, in this case, will be sent as an empty assertion data element.
InitiateReceiveAssertNone The Initiating Gateway has no awareness of responses to it that contain Carequality policy assertions. Responses to the Initiating Gateway that contain Carequality policy assertions will not result in syntax parsing errors by the Initiating Gateway, and will be ignored by the Initiating Gateway.

On the Responding Gateway side, the responder gateway EndPoint description in the Healthcare Directory must populate Bundle/entry/resource/Organization/contained/Endpoint/payloadType with one or more of the following values:

Value Description Comments
RespondSendAssertNone The Responding Gateway does not send Carequality policy assertion information in the response.
RespondSendAssertSome The Responding Gateway can send Carequality policy assertions in the response, but may not send an assertion response in all cases.
RespondSendAssertAll The Responding Gateway can send Carequality policy assertions in responses, and will send an assertion in responses in all cases.

Next Page - Carequality Usage Guidelines