Date: Thu, 28 Mar 2024 23:47:06 +0000 (UTC) Message-ID: <1289222232.1315.1711669626825@9b64b402ade9> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1314_815362470.1711669626825" ------=_Part_1314_815362470.1711669626825 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Accurate and efficient unique i= dentification of patients is an essential function for a fully realized eHe= alth architecture. A client registry (CR) is designed to support patient id= entity management. The OpenHIE CR= community seeks to foster innovative technology that provides accurate, re= liable and stable identification and de-duplication of individuals and othe= r entities in a variety of contexts, particularly resource-constrained sett= ings.
A core princip= le of the OpenHIE architecture is to allow the various infrastructure s= ervices (such as the CR) to be interchangeable. To support this,  = ;the OpenHIE Stan= dards and Profiles use by the Client Registry are outlined in the workf= lows below.
To be OHIE CR component, the CR application must be able to support the OHIE workflows listed below. Implementations may s=
upport only the workflows needed to support their use case:
A core princip= le of the OpenHIE architecture is to allow the various infrastructure s= ervices (such as the CR) to be interchangeable. See: OpenHIE Standards and Profiles.&nbs= p;
Dependi= ng upon the desired use case(s), the system may support many or all of thes= e functional features.
Configurable E= ntity matching - A service to assist in identifying d= uplicate patients
The rules for determin=
ing whether two records match each other should be configurable.
The blocking strategy = for loading potential matches before the matching rules are applied should = be configurable.
Any configurable compo= nent should have an interface so that advanced users can write their own im= plementation from scratch if desired.
Any interface should h= ave at least one default implementation.
The default implementa= tion should be flexible and configurable so that non-programmers can adjust= it to meet their needs.
To the extent possible= , CR system configuration information should be managed using consistent an= d easy to access methods, such as a database, properties files, or XM= L files).
It should allow =E2=80= =9Cwizard-based=E2=80=9D or =E2=80=9Cguided=E2=80=9D setup of matching rule= s
Patient Linking and = De-duplication
The system should implemen= t accurate and efficient patient linking and de-duplication methods.=
It should provide an easy = to use and intuitive way to see merge/linkage operations
It should allow an easy to= use and intuitive way of manually accepting or rejecting merge suggestions= , with the ability to choose fields from either record to be merged<= /p>
Configure and monito= r inbound/outbound transactions.
The system must have t= he capacity to record receipt and transmission of transactions.
<= /li>Synchronize cl= ient IDs with a SHR. (Support patient-level clinical data OHIE wor= kflow)
UI to search p= atients, manually edit (e.g., create, update, merge, split, and de= precate)
UI to review a= nd manually adjudicate uncertain (=E2=80=9Cpotential=E2=80=9D) mat= ches, and override incorrect matches.
Configurable Attribu= tes -
The attributes that fo= rm a patient record and are used for matching should be configurable.
The implementation can= include an example/default patient schema.
It should be easy to a= dd attributes to the schema.
It should also be easy= to remove attributes from the default model (or start over from scratch).<= /span>
Error Management: Ensure that error handling comprehensively captures and logs all rela= ted exceptions, and to the extent possible, shows relationships between exc= eptions.
Logging:
Privacy/Security: The system should have functions including u= ser management and access controls.
Pediatric Option: it is mandatory for an OpenHIE-conformant CR = to support the PIX =E2=80=9CPediatric Option=E2=80=9D
System configuration: = Defines entity features, identity sources, decision models, bu= siness process rules.
Data persistence: Supports reliable low latency, high bandwidth access to potentiall= y large volumes of patient identity information.
Object Representations= of Patients
An incoming patient re= cord should not need to be converted into many different formats prior to s= toring in a database.
A process like this sh= ould be sufficient:
An HL7 message is received= , representing the patient as a PID segment within the text
An HL7 library (like HAPI)= parses the message, creating an instance of a PID Java object
= li>The Client Registry conver= ts the PID object into an instance of its own patient/entity/whatever class=
That object is loaded into= the database
Scales to millions of patients: Client registries are increasingly = expected to support unique at edification of large patient populations. The= CR design must support efficient operation (sub-second response time to id= entity queries) when managing millions of patients.
An OpenHIE component should consider the following OpenHIE Non-Functional = Requirements - Draft