Patient Analytics and Patient 360: Building a Single View of the Patient
A single view of the patient is one of the most widely agreed ambitions in healthcare and one of the least often achieved. Hospitals want it for continuity of care. Pharmaceutical companies want it for adherence and evidence. Digital health providers assume they already have it. Very few of them do, and the reasons are consistent enough to be worth setting out before any platform is chosen.
That omission has a cost. A patient 360 is not one thing; it is four different things depending on whether a hospital, an insurer, a pharmaceutical company or a digital health provider is building it, and the four differ in what data is available, what the legal basis is, and what the view is actually for. Collapsing them is the reason so many programmes are approved in a strategy deck and stall in legal review — and why pharmaceutical companies keep being sold an architecture that was designed for provider IT departments.
This guide separates the terms and then the entitlements. Patient master data management, patient 360 and patient analytics are sequential rather than interchangeable, and building the third without the first produces analytics that count records rather than people. From there it covers how patient matching actually works, why over-linking and under-linking are not symmetric errors, how tokenisation lets a pharmaceutical company analyse patient-level data without holding identifiers, and what the DPDP Act changes about all of it in India.
What is a patient 360, and whose is it?
Search for patient 360 and the results are integration blueprints published by platform vendors: connect the electronic health record to the customer platform, unify the profile, surface it to a care team. The engineering is sound. What is almost entirely missing is the prior question, which determines whether any of it is buildable.
A patient 360 is not one thing. It is four different things depending on who is assembling it, and the four differ in what data is available, what the legal basis is, and what the view is actually for. Collapsing them is the reason so many programmes are approved in a strategy deck and stall in legal review.
| Who is building it | What they can legitimately assemble | Legal basis | What it is genuinely for |
|---|---|---|---|
| Provider — hospital or clinic network | Registration, clinical encounters, diagnostics, pharmacy, billing, appointments, digital channels. The richest and most complete version, and the only one that includes the clinical record | Care delivery, with consent and purpose limitation for any secondary use | Continuity of care, reducing repeat investigation, referral integrity, service line planning |
| Payer or insurer | Claims across providers, eligibility, network utilisation. Broad across facilities and shallow within each | The insurance contract, plus applicable data protection obligations | Utilisation management, network design, cost prediction |
| Pharmaceutical company | Consented patient support programme data, and de-identified or tokenised real-world data. Not the clinical record | Consent for the programme, and de-identification or anonymisation for research data | Adherence support, patient services, safety, and evidence generation |
| Digital health or diagnostics provider | Its own service encounters, plus whatever a patient consents to share through a health data exchange | Consent, and participation terms of any exchange | Service continuity and personalisation within its own relationship |
The distinction that governs everything else in this article
A pharmaceutical company cannot build a provider's patient 360, and should stop being sold one. It does not hold the clinical record, it has no lawful route to it in most markets, and the vendor architectures that dominate this subject were written for provider IT departments.
What a pharmaceutical company can build is genuinely valuable and quite different: a consented view of the patients enrolled in its own support programmes, and a de-identified, linked view of populations for evidence generation. Both are legitimate. Neither is the thing the vendor diagram shows.
The practical test before any patient 360 investment: name the legal basis for each source in the diagram. Sources without one are not part of the plan, however good the integration story is.
Patient analytics, patient 360 and patient MDM are not the same thing
These three terms are used interchangeably across most published material, including by vendors who sell one and describe it as all three. They are sequential, and the order matters more than the definitions.
| Term | What it actually is | What it produces | What goes wrong when it is skipped |
|---|---|---|---|
| Patient master data management (patient MDM) | The discipline of establishing one authoritative record per real person across every source system, and keeping it correct as data changes | A master patient index — a resolved identity with a stable internal identifier and a full map of its source records | Everything downstream counts the same person more than once. Analytics report activity for records rather than people, which is a different and wrong number |
| Patient 360 | The assembled view built on top of resolved identity — demographics, encounters, diagnostics, medications, interactions and consent state in one place | A usable record for a clinician, a care coordinator or a service team | Without MDM it becomes a 360-degree view of a fragment. The interface looks complete, which makes the gap harder to notice, not easier |
| Patient analytics | The analysis performed on the resolved population — cohorts, adherence, risk, journey, outcome and service line performance | Decisions: who to contact, which pathway to change, where capacity is short | Models trained on fragmented records learn the fragmentation. A patient appearing three times looks like three patients with short, incomplete histories |
The reason this ordering is worth stating plainly is commercial. Patient analytics demonstrates well and patient MDM does not. A cohort dashboard can be shown to a board in ten minutes; a master patient index cannot be shown at all, because its output is the absence of a problem. Programmes are therefore routinely funded in the wrong order, and the analytics layer is then blamed for producing numbers that clinicians recognise as wrong.
Why is identity resolution the hard part of a patient 360?
Because the same person does not arrive in your systems the same way twice. A patient registers at the front desk with one spelling, at the laboratory with an initial, on the app with a different mobile number, and at the insurance desk with a name matching the policy rather than the person. Every one of those is a record. None of them is wrong, and all of them are the same patient.
The measured scale of the problem, from US data: Black Book research found an average of 18% of patient records within an organisation are duplicates, against an ONC target of under 2% per facility and a longer-term goal of a hundredth of a percent. The consequences are costed: around $1,950 in duplicate care per inpatient stay and over $1,700 per emergency department visit, with 35% of all denied claims attributed to inaccurate patient identification, an average of $2.5 million a year per hospital and more than $6.7 billion annually across the US system.|
| Why identity breaks | How it shows up | Why it is not solved by better data entry |
|---|---|---|
| Name variation | Initials, honorifics, transliteration, married and maiden surnames, inconsistent word order | In multilingual markets transliteration alone produces several defensible spellings of the same name. Neither is a typing error |
| Unstable contact details | One mobile number across a family, changed numbers, a relative's number recorded at admission | A shared or borrowed number is accurate at the point of capture and still merges two people if used as a matching key |
| Partial identifiers | Date of birth recorded as a year, or an approximate age at an emergency admission | Clinically reasonable in the moment; permanently ambiguous afterwards |
| Multiple registrations by design | A patient registered separately at each facility in a network, or under a corporate scheme | The registration was correct under each system's rules. The problem is that no system owns the person |
| Time | People move, marry, change numbers and change names | A record that matched correctly in 2022 may not match in 2026. Resolution is a running process, not a project |
There is also a running cost, and it is larger than most business cases assume. A Harris and HIMSS survey found organisations spending an average of 109.6 hours a week resolving patient identity issues, with roughly ten full-time staff dedicated to the work. That is the cost of doing it manually, and it is the honest comparison for any automation business case — not a hypothetical saving, but a visible headcount already committed.
How patient matching actually works
Three approaches, used in combination rather than in competition. Understanding the difference matters because the failure modes are opposite, and choosing a threshold is choosing which failure you prefer.
| Approach | How it decides | Strength | Failure mode |
|---|---|---|---|
| Deterministic | Exact agreement on defined key fields — an identifier, or a combination such as name plus date of birth plus mobile | Precise, explainable and auditable. A match can be justified field by field | Brittle. One inconsistent character prevents a correct match, so it under-links and quietly leaves duplicates in place |
| Probabilistic | Weighted similarity across many fields produces a score, and thresholds decide match, no-match or manual review | Tolerates real-world variation — the only approach that handles transliteration and partial data at scale | Threshold-dependent. Set it loose and distinct people merge; set it tight and duplicates persist. The middle band needs human review |
| Referential | Matching against an external reference of known identity data, rather than only comparing your records with each other | Resolves cases your own data cannot — a moved patient, a changed surname | Depends on the reference's coverage and currency, which vary sharply by market |
The two errors are not symmetric, and the design choice belongs to a clinician
Under-linking leaves one person as several records. The visible cost is incomplete history, repeated investigation and understated engagement. It is the default state and it is tolerated because it is invisible.
Over-linking merges two people into one record. In a commercial database that is a data quality issue. In a clinical record it is a patient safety event: one person's allergy, medication or result attached to another person.
This asymmetry is why patient matching thresholds are set more conservatively than customer matching thresholds, and why a manual review queue is a feature rather than a failure. The threshold decision is a clinical governance decision, not a technical one, and it should be signed off accordingly.
How pharmaceutical companies build patient-level analytics without holding identifiers
This is the mechanism that makes patient analytics possible for an organisation with no lawful route to the clinical record, and it is almost absent from general patient 360 content because that content is written for providers.
Tokenisation replaces direct identifiers with cryptographic tokens derived from demographic data, so that records belonging to the same person can be joined across datasets without any party sharing names, dates of birth or national identifiers. The typical inputs are full date of birth, postal code and sex, with first and last name where available. Token-to-identifier mappings are held separately under encryption and access control, and re-identification is restricted to a neutral custodian under an approved protocol.
| Token type | Behaviour | Use | Limitation |
|---|---|---|---|
| Deterministic | The same input always produces the same token | Longitudinal tracking of one patient across sources — the property that makes linkage possible | Reproducible by design, so the surrounding controls carry the privacy burden |
| Randomised | A unique token per application | Maximum obfuscation | Precludes linkage, which removes the reason to tokenise in the first place |
| Referential | Cryptographic hashing of demographics combined with a managed reference repository | The approach used for regulatory-grade work | Depends on the custodian's coverage and governance |
On performance, published guidance sets a minimum standard of match precision of 95% or better, validated against gold-standard test sets or clerical review, and one reported psoriasis trial achieved over 99% linkage precision joining electronic health records with claims data. Those figures are worth stating precisely because they are often quoted loosely: they describe precision of the matches made, not the share of a population successfully linked, and the two are different questions.
The two linkage errors, and why the analysis must report both
Over-linking falsely aggregates clinical events belonging to different people, which introduces confounding bias — the events look like one patient's trajectory and are not. In an evidence study that is not a data quality footnote; it is a wrong finding.
Under-linking produces incomplete patient profiles, which biases in the opposite direction by truncating histories and understating exposure or duration.
Both are made worse by inadequate preprocessing: without harmonisation across sources with different formats and completeness, tokenisation generates mismatches rather than resolving them. A credible patient-level analysis states its linkage rate and its precision, not just its result — and a vendor unwilling to report both should be asked why.
The India reality: what DPDP changes about patient data
Most patient 360 guidance assumes an American regulatory frame — HIPAA, de-identification safe harbours, a mature tokenisation market and claims data as a linking backbone. Very little of that transfers. India's position is different in ways that change the design, not merely the paperwork.
| What people assume | What is actually the case under DPDP | Design consequence |
|---|---|---|
| "Health data is a special sensitive category with its own rules" | The Act does not create a separate statutory category of sensitive personal data as GDPR does. India took a risk-based approach in which potential for harm drives the rigour expected | Do not build a control model around a category that does not exist. Build it around demonstrable harm and purpose |
| "We de-identified it, so the law no longer applies" | Exemptions depend on effective anonymisation, and anonymisation is not assumed. Where re-identification keys are retained and data remains linkable, it is likely still personal data with full obligations | Holding the key means holding the obligation. Custody design decides the compliance position, not the label on the dataset |
| "Our existing patient consent covers analytics" | Consent must be free, informed, specific, unambiguous and withdrawable. Broad future-use clauses and blanket permissions are exactly what fails | Granular, purpose-specific consent capture, and the ability to enforce a withdrawal across every downstream system |
| "We are a normal data controller" | Healthcare entities processing patient information are strong candidates for Significant Data Fiduciary designation, which adds an India-based data protection officer, independent audits and impact assessments | Budget for governance roles, not only for platform |
| "Research data is exempt" | Research exemptions are not blanket carve-outs and depend on the anonymisation position. Secondary uses, including AI model training, need fresh justification | Write the secondary-use question into the original consent design, because retrofitting it is far harder |
There is a constructive side to the Indian position that deserves as much attention as the constraints. The Ayushman Bharat Digital Mission passed 100 crore health records linked to ABHA accounts on 22 May 2026, roughly double the February 2025 figure, with more than 450 integrated health technology solutions. That is a national patient identity and record-exchange layer of a kind most health systems do not have — and it is consent-based and built for care delivery, which means it is an interoperability foundation rather than a data source to be acquired.
What can a pharmaceutical company in India actually build?
Four routes, in descending order of how quickly they become usable. None of them is the provider's patient 360, and each is legitimate on its own terms.
| Route | What it gives you | Legal basis and the condition attached | Realistic timeline |
|---|---|---|---|
| 1. Patient support programme 360 | A complete, consented view of enrolled patients — enrolment, adherence, refill behaviour, counselling contact, outcomes reported by the patient | Direct consent from the patient for a named purpose. The condition is that the consent is specific and withdrawal cascades to every system | One to two quarters. The fastest legitimate route and the most under-built |
| 2. De-identified population analytics | Cohort-level incidence, treatment pattern and adherence analysis | Effective anonymisation, assessed honestly rather than asserted | Two quarters, dependent on source agreements |
| 3. Tokenised linked datasets | Patient-level longitudinal analysis across sources without holding identifiers | De-identification with custody separated from the sponsor. The Indian data supply for this is far thinner than the US equivalent | Longer, and market-dependent. Verify data availability before designing around it |
| 4. Provider partnership analytics | Insight from a hospital's own resolved data, produced within the hospital's governance | The provider's basis, not yours. The analysis goes to the data; the data does not come to you | Ongoing, and relationship-limited |
The under-built opportunity is route one, and it is not a technology problem
Most Indian pharmaceutical companies run patient support programmes, and most run them on a mix of a call-centre system, a spreadsheet and a partner's platform, with the data fragmented across all three and consent recorded on paper.
That is the one patient population a pharmaceutical company has an unambiguous, consented relationship with, and it is routinely the least well instrumented data in the company — while the same organisation debates acquiring patient-level data it has no lawful route to.
Resolve the identity of your own enrolled patients, capture consent granularly and digitally, and make withdrawal work end to end. It is achievable in two quarters, it is defensible under DPDP, and it produces the adherence and outcome evidence that the acquired-data conversation was trying to reach.
A worked example: resolving one hospital network's patient identity
Numbers make this concrete. The following walks an illustrative multi-site hospital network through identity resolution. The figures demonstrate the method and the shape of the result rather than reporting a specific engagement.
Step 1 — the starting position
| Source system | Records | Identity fields available | Known issue |
|---|---|---|---|
| Hospital information system, four sites | 1,240,000 | Name, age or date of birth, mobile, address, site MRN | Each site issues its own medical record number. A patient treated at two sites is two patients |
| Laboratory information system | 890,000 | Name, age, mobile, referring doctor | Walk-in tests often recorded with age rather than date of birth |
| Pharmacy | 610,000 | Name, mobile | Frequently the attendant's mobile number, not the patient's |
| Appointment and call centre | 430,000 | Name, mobile, requested specialty | No clinical identifier at all |
| App and web registrations | 180,000 | Name, mobile, email, date of birth | The cleanest source, and the smallest |
| Insurance and corporate scheme desk | 150,000 | Name as per policy, policy number, employer | Name matches the policy document rather than the person |
Step 2 — what resolution produces
| Stage | Result | Reading |
|---|---|---|
| Raw record count across sources | 3,500,000 | The number the systems report, and the number most dashboards silently use |
| After deterministic matching on exact keys | 2,980,000 distinct records | Removes the easy duplicates only. Roughly 15% collapse, all of it exact-match |
| After probabilistic matching at a conservative threshold | 2,120,000 estimated distinct patients | A further 29% collapse. This is where the real duplication was |
| Records routed to manual review | 64,000, about 3% | The ambiguous band. Not a failure — the queue is the safety mechanism |
| Confirmed cross-site duplicates | 310,000 patients seen at more than one site | Previously invisible. Each was a discontinuous history |
The headline is that a network reporting 3.5 million patient records has roughly 2.1 million actual patients — and that every per-patient metric computed before resolution was wrong in a predictable direction. Visit frequency was understated, repeat-visit rates were understated, and patient acquisition was overstated, because a returning patient registering at a second site was counted as a new one.
Step 3 — what changes as a result
- Repeat-visit and retention metrics move materially, because 310,000 patients previously counted as separate people at each site become continuous histories. Retention was never as poor as it appeared
- Marketing acquisition cost per patient rises and becomes correct. Spending divided by inflated new-patient counts flattered every channel, and the flattery was uneven — channels serving multi-site catchments looked best and were most affected
- Clinical continuity improves at the point of care, which is the benefit that justifies the work independently of any analytics case: a clinician at the second site can see the first site's history
- The manual review queue becomes a permanent function, not a project task. Around 3% of records needing human adjudication is a normal steady state, and staffing it is part of the operating cost
Where patient 360 programmes fail
- Buying the view before resolving the identity. The interface is assembled on unresolved records, looks complete, and shows a fragment. A convincing incomplete view is more damaging than an obviously incomplete one, because nobody investigates it.
- Treating matching thresholds as a technical setting. Over-linking in a clinical record is a patient safety event, not a data quality issue. The threshold and the review queue need clinical governance sign-off.
- Assuming de-identification removes the obligation. Under DPDP, exemptions depend on effective anonymisation, and retained re-identification keys mean the data is likely still personal data. The label on the dataset is not the compliance position.
- Designing a pharmaceutical patient 360 from a provider blueprint. The clinical record is not available and no integration diagram makes it so. The result is a programme that cannot pass legal review after the platform has been bought.
- Relying on blanket historical consent. Broad future-use clauses are precisely what the consent standard is written against, and the exposure sits in the legacy patient database rather than in new capture.
- Quoting linkage precision as population coverage. A 99% precision figure describes the matches that were made. It says nothing about the share of the population successfully linked, and the two get conflated in almost every vendor deck.
- Funding resolution as a project rather than a function. People move, marry and change numbers. A master patient index left unmaintained degrades from the day it is delivered, and the review queue is the mechanism that stops it.
A phased plan for building a patient 360
Sequenced so that each phase is a prerequisite for the next, and so the governance decisions are made before the platform choices.
- Phase one — establish who is building it and on what basis. Write down each source, its legal basis and its consent state. Sources without an identified basis leave the diagram now, not after procurement. For a pharmaceutical company this phase usually reveals that the realistic scope is the support programme population, which is a useful finding rather than a disappointing one.
- Phase two — profile the identity problem before buying anything. Sample the records, measure the duplication rate, and establish which fields are actually populated and reliable. A network that has never measured its duplication rate cannot size the work, and the measurement takes days rather than months.
- Phase three — resolve identity, with the review queue designed in. Deterministic matching first for the exact cases, probabilistic matching at a clinically-approved threshold second, and a staffed adjudication queue for the ambiguous band. Agree the over-linking tolerance with clinical governance before go-live, not after the first incident.
- Phase four — assemble the view, and instrument consent alongside it. Bring the resolved record together with encounters, results and interactions — and carry the consent state as a first-class field, so that withdrawal can be enforced at the point of use rather than reconciled later.
- Phase five — analytics, and re-baseline everything. Cohorts, adherence, journey and service line analysis on the resolved population. Expect the historical numbers to change, and communicate that before it happens. A retention rate that improves because the counting was fixed will otherwise be mistaken for a performance claim.
One expectation to set at the outset. Phases one to three produce no visible product and consume most of the timeline. They are also the reason phases four and five produce anything at all, and a steering committee judging progress on demonstrations at the halfway point will push to invert the order — which is the first failure mode listed above.
Key takeaways
The seven actions this article argues for, separated from the evidence that supports them.
- Establish who is building the patient 360 before designing it. A hospital, an insurer, a pharmaceutical company and a digital health provider are entitled to assemble very different views of the same patient.
- Name the legal basis for every source in the diagram. Sources without one leave the plan now, not after the platform has been procured.
- Measure your duplication rate before buying anything. It takes days, it sizes the work, and a network that has never measured it cannot scope the project honestly.
- Treat the matching threshold as a clinical governance decision. Over-linking in a clinical record is a patient safety event, not a data quality issue, and the review queue is a feature rather than a failure.
- Build the patient support programme 360 first if you are a pharmaceutical company in India. It is consented, it is yours, it is achievable in two quarters, and it is usually the least well instrumented data in the business.
- Do not assume de-identification removes the obligation. Under DPDP, exemptions depend on effective anonymisation, and retained re-identification keys mean the data is likely still personal data.
- Report linkage rate and precision together. A 99% precision figure describes the matches that were made and says nothing about the share of the population successfully linked.
Conclusion
A patient 360 is usually presented as an integration problem and is almost always an identity problem wearing an integration problem's clothes. The systems can be connected in weeks. Establishing that one person is one record, and keeping that true as people move, marry and change contact details, is the work that takes quarters and produces nothing anyone can demonstrate.
The second constraint is the one the vendor literature omits entirely, and it is the reason so many programmes are approved and then stall. Whose patient 360 it is determines what can lawfully be assembled, and a pharmaceutical company cannot build a provider's version however good the integration story is. What it can build — a consented view of its own support programme population, and a de-identified linked view for evidence generation — is genuinely valuable and quite different from the diagram it is usually shown.
The four steps that matter cost weeks and almost no money: establish who is building it, name the legal basis for each source, measure the duplication rate, and treat the matching threshold as a clinical decision. Everything bought afterwards depends on those four having been done honestly, and no platform compensates for skipping them.
Frequently Asked Questions For Patient Analytics and Patient 360
A single, resolved record that brings every interaction with one patient into one view — demographics, encounters, diagnostics, medications, appointments, digital interactions and consent state. The defining feature is not the breadth of the view but the resolution underneath it: one record per real person, not one record per registration. It is built on patient master data management, which establishes that resolved identity, and it is the layer that patient analytics runs on. Whose patient 360 it is matters as much as what is in it, because a hospital, an insurer and a pharmaceutical company are entitled to assemble very different views of the same patient.
They are sequential rather than interchangeable. Patient MDM is the discipline of establishing one authoritative record per real person across every source system and keeping it correct as data changes; its output is a master patient index. Patient 360 is the assembled view built on that resolved identity. Patient analytics is the analysis performed on the resolved population — cohorts, adherence, risk, journey and service line performance. Skipping the first produces analytics that count records rather than people, which is a different and wrong number, and the mistake is common because analytics demonstrates well to a board and master data management cannot be demonstrated at all.
Because the same person does not arrive in your systems the same way twice, and most of the variation is not error. Names vary through initials, transliteration, honorifics and marriage; mobile numbers are shared within families or borrowed at admission; date of birth is recorded as an approximate age in an emergency; and each facility in a network issues its own medical record number. US data illustrates the scale: Black Book research found an average of 18% of patient records within an organisation are duplicates, against an ONC target of under 2% per facility. It is also a running cost — a Harris and HIMSS survey found organisations spending around 109.6 hours a week and roughly ten full-time staff resolving identity issues.
The documented figures are American and should be read as such. AHIMA figures put duplicate care at approximately $1,950 per inpatient stay and over $1,700 per emergency department visit, attribute 35% of all denied claims to inaccurate patient identification, and estimate an average of $2.5 million a year per hospital and more than $6.7 billion annually across the US health system. These are US figures reflecting US billing structures and should not be applied directly to Indian operations, where the cost profile is dominated by repeat investigation, clinical discontinuity and analytics that misstate retention rather than by claim denials.
Through tokenisation. Demographic elements — typically full date of birth, postal code and sex, with name where available — are cryptographically hashed into tokens, so records belonging to the same person can be joined across datasets without any party sharing identifiers. Token-to-identifier mappings are held separately under encryption and access control, with re-identification restricted to a neutral custodian under an approved protocol. Published guidance sets a minimum match precision of 95% or better, and one psoriasis trial reported over 99% linkage precision joining electronic health records with claims data. Read those as precision of the matches made, not the share of a population linked — the two are routinely conflated.
Not as a separate statutory category. Unlike GDPR, the DPDP Act does not create a distinct class of sensitive personal data; India took a risk-based approach in which the potential for harm determines the rigour expected. In practice health data attracts heightened scrutiny anyway, and healthcare entities processing patient information are strong candidates for Significant Data Fiduciary designation, which brings an India-based data protection officer, independent audits and data protection impact assessments. Two further points matter for analytics: consent must be specific and withdrawable rather than blanket, and anonymisation is not assumed — where re-identification keys are retained and data remains linkable, it is likely still personal data with full obligations attached.
Not the provider's version, and it should stop being sold one — it does not hold the clinical record and has no lawful route to it. What it can build is four things, in descending order of speed: a consented patient support programme 360 covering enrolled patients, which is the fastest legitimate route and usually the most under-built; de-identified population analytics; tokenised linked datasets, where Indian data supply is considerably thinner than the American equivalent and should be verified before a design depends on it; and provider partnership analytics, where the analysis goes to the data under the hospital's governance rather than the data coming to the sponsor.
The honest answer separates the phases. Establishing the legal basis for each source takes weeks and often reduces the scope, which is a useful outcome. Profiling the duplication rate takes days. Identity resolution itself is the long phase — typically one to two quarters for a multi-site network — and it is followed by view assembly and then analytics. Expect roughly 3% of records to require manual adjudication as a permanent steady state, staffed as an ongoing function rather than a project task, because people move, marry and change contact details and a master patient index degrades from the day it is delivered if nobody maintains it.
Let's Discuss Your Requirements
