Health Information Technologies and Processes

Establishing Patient Identification

  • 1.  Establishing Patient Identification

    Posted 03-18-2020 17:24

    Key Points

    • Correct patient identification is vital for patient safety and the maintenance of patient confidentiality.
    • States have been implementing two methods of establishing patient identification.

    Protected Health Information

     The HIPAA Privacy Rule protects most individually identifiable health information held or transmitted by a covered entity or its business associate, in any form or medium, whether electronic, on paper, or oral. The Privacy Rule calls this information protected health information (PHI)2. Protected health information is information, including demographic information, which relates to:

    • the individual's past, present, or future physical or mental health or condition,
    • the provision of health care to the individual, or
    • the past, present, or future payment for the provision of health care to the individual, and that identifies the individual or for which there is a reasonable basis to believe can be used to identify the individual. Protected health information includes many common identifiers (e.g., name, address, birth date, Social Security Number) when they can be associated with the health information listed above.

    Sources

    There are several sources for identifying a patient in HL7 messaging standards.

    • IHE (Integrating the Healthcare Enterprise)
    • Standards of Practice for Patient Identification – Association of Surgical Technologists
    • HL7 Version 2.x messages
    • HL7 Version 3 – CCD messages
    • HL7 FHIR
    • DICOM

    IHE (Integrating the Healthcare Enterprise)

    IHE is a profiling organization. IHE provides Integration Profiles and Technical Frameworks that can be used for guidance in identifying Patient Identification.

    IHE IT Infrastructure Domain Profiles

    -

    IHE defines the Patient Identifier Domain as a single system or a set of interconnected systems that all share a common identification scheme (an identifier and an assignment process to a patient) and issuing authority for patient identifiers.


    HL7 Profiles

    There are three IHE profiles that support Patient Identification.

    • Patient Identifier Cross-Referencing (PIX)
    • Cross-Community Patient Discovery (XCPD)
    • Patient Identifier Cross-Referencing for HL7v3 (PIXv3)

    Patient Identifier Cross-Referencing (PIX)

    The Patient Identifier Cross-Referencing (PIX) profile supports the cross-referencing of patient identifiers from multiple Patient Identifier Domains. HL7 V2.x is the message format. Supports determination of matching patient identifiers (ADT^A01, A04, A05, A08, A31, A40; Q23)

    Process Flow
    Source: IHE

    Cross-Community Patient Discovery (XCPD)

    The Cross-Community Patient Discovery (XCPD) profile supports the means to locate communities that hold patient-relevant health data.

    Patient Identifier Cross-Referencing for HL7v3 (PIXv3)

    The Patient Identifier Cross-Referencing for HL7v3 (PIXv3) profile provides cross-referencing of patient identifiers from multiple Patient Identifier Domains. HL7 V3 is the message format.

    Actor and Transactions
    Source: IHE

    Dicom Profiles

    Patient Information Reconciliation (PIR)

    This profile coordinates reconciliation of the patient record when images are acquired for unidentified (e.g. trauma), or misidentified patients.

    Nuclear Medicine Image (NMI)

    This profile specifies how Nuclear Medicine images and result screens are created, exchanged, used and displayed.

    Workflows

    Scheduled Workflow (SWF)

    This workflow integrates the ordering, scheduling, imaging acquisition, storage and viewing activities associated with radiology exams.

    Scheduled Workflow establishes a seamless flow of information that supports efficient patient care workflow in a typical imaging encounter. It specifies transactions that maintain the consistency of patient information from registration through ordering, scheduling, imaging acquisition, storage and viewing as shown in the following figure.

    Scheduled Workflow
    Source: IHE

    Anatomy of a Dicom file

    As we already know a DICOM file storing one image contain the image data and data belonging to the patient and data (name, age, etc.) belonging to the examination (date of acquisition, manufacturer, etc.) and identifiers: the study UID, the series' UID's, and the image UID's.

    The software that interprets the image will have to be able to find, first of all, the part of the DICOM file containing the image; also all of the identifiers and the other data contained in the DICOM file. The DICOM standard has a special pair of characters, the parentheses and the comma: '(' and ')' and ','. Now, numbers of 2×4 hexadecimal digits enclosed by these parentheses and separated by the comma uniquely identify a specific DICOM field or data. For instance this tag:

    (0010,0010) is the identifier of the patient's name – „ten-ten is the patient name" as DICOM experts would say. The last thing that we have to learn is that the data, in this case, the patient name is enclosed by a pair of the tag shown above:

    Here is a decoded segment of the DICOM information found in a DICOM file:

    Dicom-File-Format for Patient Identification

    The following table defines the attributes relevant to identifying a patient

    Attribute Name Tag Attribute Description
    Patient\'s Name (0010,0010) Patient\'s full name
    Patient ID (0010,0020) Primary identifier for the patient.
    Other Patient IDs (0010,1000) Other identification numbers or codes used to identify the patient.
    Other Patient IDs Sequence (0010,1002) A sequence of identification numbers or codes used to identify the patient, which may or may not be human-readable, and may or may not have been obtained from an implanted or attached device such as an RFID or barcode.
    Type of Patient ID (0010,0020) The type of identifier in this item.

    Enumerated Values:
    TEXT RFID

    BARCODE |
    | Other Patient Names | (0010,1001) | Other names used to identify the patient. |
    | Patient\'s Birth Name | (0010,1005) | Patient\'s birth name. |
    | Patient\'s Mother\'s Birth Name | (0010,1060) | Birth name of patient\'s mother. |
    | Medical Record Locator | (0010,1090) | An identifier used to find the patient\'s existing medical record (e.g., film jacket). |
    | Referenced Patient Photo Sequence | (0010,1100) | A photo to confirm the identity of a patient.
    Only a single Item is permitted in this Sequence. |

    Standards of Practice for Patient Identification – Association of Surgical Technologists

    Standard of Practice I

    The use of two patient identifiers improves the reliability of the patient
    identification process and decreases the chance of performing the wrong
    procedure on the wrong patient. Additionally, the use of two patient identifiers is
    necessary in the instances of a name patient alert because of two (or more patients)
    have the same name that can be spelled the same, close to being spelled the same
    and/or pronounced the same.

     NOTE: The patient's room number should not be used as a patient identifier; room numbers are not person-specific identifiers, since patients can be moved from room to room

    Standard of Practice II

    All patients undergoing a surgical procedure should wear an identifying marker.

    HL7 Version 2.x messages

    HL7 PID Segment

    The HL7 PID segment is found in every type of ADT message (i.e. ADT-A01, ADT-A08, etc.) and contains 30 different fields with values ranging from patient ID number, to patient sex, to address, to marital status, to citizenship. The PID segment provides important identification information about the patient and, in fact, is used as the primary means of communicating the identifying and demographic information about a patient between systems.

    The HL7 standard allows for several different types of patient identification numbers in the first four fields of the PID segment.

    Sequence Element Name
    PID-1: Set ID – Patient ID – a number to identify the transaction
    PID-2: Patient ID (External ID) – the patient identifier number used by one or more outside institutions (i.e. a physician's office that is referring the patient)
    PID-3: Patient ID (Internal ID) – the primary, unique patient identifier number used by the facility
    PID-4: Alternate Patient ID – an alternate, additional, temporary or pending patient identification number

    Example

    The PID segment is shown in red.

    HL7 Version 3 – CCD

    The Continuity of Care Document (CCD) is built using the HL7 Clinical Document Architecture (CDA) elements and contains data that is defined by the ASTM Continuity of Care Record (CCR). It is used to share summary information about the patient within the broader context of the personal health record.

    CDA Template Types
    Source: HL7 Organization

    Record Target Section

    The recordTarget element of the header identifies the patient associated with the document and contains no narrative component.

    Example

    <recordTarget> <patientRole> <!-- CONF 5268--> <!-- Patient SSN recorded as an ID --> <id extension="123-456-7890" root="2.16.840.1.113883.4.1"/> <!-- CONF 5271 --> <addr use="HP"> <!-- HP is "primary home" from codeSystem 2.16.840.1.113883.5.1119 --> <streetAddressLine>999 Huckleberry Ave, Apt #3</streetAddressLine> <city>Springfield</city> <state>PA</state> <postalCode>19064</postalCode> <country>US</country> <!-- US is "United States" from ISO 3166-1 Country Codes: 1.0.3166.1 --> </addr> <!-- CONF 5280 --> <telecom value="tel:+1(610)555-0000" use="HP"/> <!-- HP is "primary home" from HL7 AddressUse 2.16.840.1.113883.5.1119 --> <telecom value="tel:+1(610)555-1111" use="MC"/> <!-- MC is "mobile contact" from HL7 AddressUse 2.16.840.1.113883.5.1119 --> <!-- CONF 5283 --> <patient> <!-- CONF 5284 --> <name use="L"> <!-- L is "Legal" from HL7 EntityNameUse 2.16.840.1.113883.5.45 --> <given>Jane</given> <family>Appleseed-Monroe</family> </name> <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1" displayName="Female"/> <birthTime value="19770330"/> <maritalStatusCode code="M" codeSystem="2.16.840.1.113883.5.2" codeSystemName="MaritalStatus"/> <raceCode code="2076-8" displayName="Native Hawaiian or Other Pacific Islander" codeSystem="2.16.840.1.113883.6.238" codeSystemName="OMB Standards for Race and Ethnicity"/> <sdtc:raceCode code="2054-5" displayName="Black or African American" codeSystem="2.16.840.1.113883.6.238" codeSystemName="OMB Standards for Race and Ethnicity"/> <ethnicGroupCode code="2186-5" displayName="Not Hispanic or Latino" codeSystem="2.16.840.1.113883.6.238" codeSystemName="OMB Standards for Race and Ethnicity"/> <languageCommunication> <!-- CONF 5407: LanguageCode Code System 2.16.840.1.113883.1.11.11526 --> <languageCode code="en"/> <modeCode code="ESP" displayName="Expressed spoken" codeSystem="2.16.840.1.113883.5.60" codeSystemName="LanguageAbilityMode"/> <preferenceInd value="true"/> </languageCommunication> </patient> </patientRole> </recordTarget>

    HIE Sources

    Record Locator Service

    Record Locator Service (RLS) - The Record Locator Service is the only new piece of infrastructure required by the Health Information Environment. A RLS is subject to privacy and security requirements and is based on open standards set by the Standards and Policy Entity.

    The RLS holds information authorized by the patient about where authorized information can be found, but not the actual information the records may contain. It thus enables a separation, for reasons of security, privacy, and the preservation of the autonomy of the participating entities, of the function of locating authorized records from the function of transferring them to authorized users.

     INFO: Release of information from one entity to another is subject to authorization requirements between those parties; in certain sensitive treatment situations patients or providers may choose not to share information.

    • RLSs are operated by multi-stakeholder collaboratives at each sub-network and are built on the current use of Master Patient Indices.
    • The Record Locator Service needs to enable a care professional looking for a specific piece of information (PCP visit or ER record) to find it rapidly. An open design question is how and wherein the model this capability can best be accomplished.

    Message Processing

    Message Processing Workflow

    The Message Processor provides all the capabilities of extracting Patient data from all HL7 Message Types. The following are examples from a Message processor application.

    Processing HL7 ADT Message Types

    Processing HL7 ADT Message Types example

    Extracting Patient information from ADT Message Types

    Extracting Patient information from ADT Message Types example

    Extracting Patient information from FHIR resources

    Extracting Patient information from FHIR Resources example

    Devices

    Device auto-provisioning

    Device auto-provisioning
    source: Auto-provisioning concepts

    Device Configuration

    Configuration
    source: Configure your devices from a back-end service
    Device Twins
    source: Understand and use device twins in IoT Hub

    Device Twin example

    { deviceId: devA, etag: AAAAAAAAAAc=, status: enabled, statusReason: provisioned, statusUpdateTime: 0001-01-01T00:00:00, connectionState: connected, lastActivityTime: 2015-02-30T16:24:48.789Z, cloudToDeviceMessageCount: 0, authenticationType: sas, x509Thumbprint: { primaryThumbprint: null, secondaryThumbprint: null }, version: 2, tags: { $etag: 123, deploymentLocation: { room: OR234, floor: 1 }, $etag: 124, patient: { id: 233x3dd3frr, 'id2': medddddd } }, properties: { desired: { telemetryConfig: { sendFrequency: 5m }, $metadata : {...}, $version: 1 }, reported: { telemetryConfig: { sendFrequency: 5m, status: success } batteryLevel: 55, $metadata : {...}, $version: 4 } } }

    References

    AHIMA STANDARDS FACT SHEET
    Patient Identification in Three Acts
    Integrating the Healthcare Enterprise (IHE)
    Healthcare Information and Management Systems Society (HIMSS)
    Association of Surgical Technologists
    DICOM
    Health Level Seven International (HL7)
    FHIR® – Fast Healthcare Interoperability Resources
    Azure IoT Fundamentals


    Extended Patient Identification

    The following figure shows the mapping between the HL7 Version 2.x and FHIR Patent Resource.

    Mapping
    source: HL7 FHIR

    Post Surgery Reporting

    The HL7 FHIR Procedure Resource is used to record the details of procedures performed on a patient.

    This resource provides summary information about the occurrence of the procedure and is not intended to provide real-time snapshots of a procedure as it unfolds.

    The following is the resource template

    Reporting

    The HL7 FHIR Procedure Resource is used to record the details of procedures performed on a patient.

    Real-world procedure example

    { resourceType: Procedure, id: f002, text: { status: generated, div: **Generated Narrative with Details**: <a>Lab results blood test</a>**followUp**: described in care plan (Details ) }, status: completed, code: { coding: [ { system: http://snomed.info/sct, code: 359615001, display: Partial lobectomy of lung } ] }, subject: { reference: Patient/f001, display: P. van de Heuvel }, context: { reference: Encounter/f002 }, performedPeriod: { start: 2013-03-08T09:00:10+01:00, end: 2013-03-08T09:30:10+01:00 }, performer: [ { role: { coding: [ { system: urn:oid:2.16.840.1.113883.2.4.15.111, code: 01.000, display: Arts } ], text: Care role }, actor: { reference: Practitioner/f003, display: M.I.M. Versteegh } } ], reasonCode: [ { text: Malignant tumor of lung } ], bodySite: [ { coding: [ { system: http://snomed.info/sct, code: 39607008, display: Lung structure } ] } ], outcome: { text: improved blood circulation }, report: [ { reference: DiagnosticReport/f001, display: Lab results blood test } ], followUp: [ { text: described in care plan } ] }

    Using DICOM Modality Worklist to send/receive patient demographics.

    What is the Modality Worklist?

    Modality Worklist is a technology or software capability associated with DICOM imaging studies that have the potential to significantly improve your workflow. When you use the Modality Worklist, the patient demographic information that has been acquired and stored in your EHR system is electronically sent to the imaging modality itself.

    Continuous Integration

    To achieve continuous integration, there needs to be additional information passed between the EHR and cloud PACS beyond just the patient\'s demographic information-some sort of unique identifier that connects the patient\'s exam within the EHR to the related imaging study in the cloud.

    A unique identifier is generated by the EHR system and is known as the accession number or exam ID. When this number is entered into an imaging modality, it makes it much easier to implement a cloud PACS EHR integration, as the two systems are able to recognize a commonality on the given exam.

    However, a unique identifier that can be up to 16 digits long is a substantial burden for many imaging technologists to enter into the modality and presents a very real possibility for human error when typing it in manually.

    This is where Modality Worklist comes in.

    It takes the information from the EHR system and provides it to the imaging modality electronically so that the technologist doesn\'t have to re-enter any of the information. The accession number can then pass to the cloud PACS along with the other DICOM fields when the image is sent. Receiving the accession number in the cloud closes the loop as it enables the EHR and cloud PACS to communicate regarding the specific exam through the use of this unique identifier.

    With this type of usage, the benefit of the Modality Worklist is greater than simply improving your workflow. It serves as a man in the middle to make PACS/EHR integrations as painless, frictionless and error-free as possible.

    Worklist Warnings

    The following list serves as warnings to the Radiologic Technologist when using the worklist.

    • Radiologic technologists should verbally (or through any other means available) confirm a patient\'s identity and demographic information before beginning an exam. This is necessary to ensure that the correct exam is selected from the worklist.
    • When an exam has ended, a technologist must complete the exam on the Modality Worklist or in IDXrad. If the technologist fails to complete the exam, the exam will still appear on the Interpretation Worklist and its images will be available for review. However, the status will remain as I (In progress), which could potentially cause confusion and delayed diagnoses and treatment.
    • Technologists can begin an exam at a different resource than the one specified during exam scheduling. Technologists must ensure that the currently selected performing resource is the appropriate resource for performing the exam.
    • Technologists can link an image set to multiple exam accession numbers for the same patient and modality. If a technologist links an exam that is not part of the study, the incorrect image set is associated with the exam\'s accession number. This may result in confusion and incorrect or delayed diagnoses and treatment.
    • Technologists can unlink an imaging study from an exam (accession number). If a technologist erroneously unlinks an image study from its appropriate accession number, the correct image study will no longer be associated with that accession number. This may result in confusion and incorrect or delayed diagnoses and treatment.
    • Technologists can unlink an image study from an exam in D (Dictated), P (Preliminary), F (Finalized), A (Addended), or R (Revised) status. If a technologist unlinks an image study from an exam in one of these statuses, the radiologist\'s diagnostic report may be affected because the report was dictated when the images were originally linked to the exam. For example, a report may make reference to or include a diagnosis based upon the image to which it was once linked. If this were the case and the image study is no longer linked to the exam/report, the image reference is lost, and the image could be lost forever if never relinked to the appropriate exam.

    Governance

    HIPAA/HITRUST

    The Azure Security and Compliance Blueprint – HIPAA/HITRUST Health Data and AI offer a turn-key deployment of an Azure PaaS solution to demonstrate how to securely ingest, store, analyze, and interact with health data while being able to meet industry compliance requirements. The blueprint helps accelerate cloud adoption and utilization for customers with data that is regulated.

    Components
    ref: Azure Secuity
    Architectural diagram
    ref: Azure Security

    Facial Recognition – Not just the surface

    Use Case

    1. When a patient is admitted, a front-facing photo is taken.
    2. The photo is stored either locally or in Azure Blob Storage.
    3. The URI for the image is inserted into an HL7 Version 2.x OBX-5 message.
    4. Once the Processor Service receives the message it is added to the HL7 FHIR Patient Resource.
    5. When the patient is brought into the Operating Room, a facial scan is performed.
    6. It is verified using the Azure Cogitative Face API Service.

    Solving the problem

    I have been developing an extension device that can be attached to a Cell Phone or Pad.

    I have several 3-D Cameras and am also working with the Azure Kinect SDK.
    I am currently training the device software to detect not just the face, but the complete muscle and bone structure. The following video shows what I am targeting.

    Patient Identification Device

    • The device will have it own camera or can be used with the phone or pad own camera.
    • It will use the phone or pads WiFI to connect to a IoT Edge Server
    • The server could connect to Azure to synchronize the Patient images.
    • The server would also store the patients image .
    • Since the server has only one purpose, a Raspberry PI 4 or a Nano Jetson with the Extension Board for a 1-TB SSD would be all that is needed.
    • The Server would run Linux and be configured as an HL7 FHIR Server and API.
    • It would only contain the FHIR Resources for Medical Devices and Patient data.
    • All data would be encrypted in flight and at REST.

     I am not in the business of selling products. I normally open-source everything.
    I plan on providing a complete tutorial for those that want to build the recognition software. I don't want to see it ending up being sold by a device manufacturer.



    ------------------------------
    Howard Edidin
    Hl7 Fhir Sme
    ------------------------------