eduKateSG · Why Science?
Send a governed question across connected services, compare the returned evidence and let people—not a match score alone—decide what deserves collaboration
Choose the closest route, then return to the full index whenever you need the wider evidence chain.
Science learning becomes powerful when students can tell a measured pattern from a model, a statistical decision from a mechanism, and a useful lead from a finished conclusion. Matchmaker Exchange, or MME, is a federated project connecting rare-disease matching services through standard application programming interfaces and shared procedural conventions. Its official overview says the project was launched in 2013 to help find similar cases by phenotypic and genotypic profiles across otherwise isolated databases. The March 2026 service requirements cover connections, test data, notifications, metrics, disclaimers, security and participation. Each connected node retains its own users, data, matching algorithm and notification protocol. A returned match is an invitation to inspect evidence and collaborate; it is not an automatic gene discovery, variant classification or diagnosis. This guide supports Primary Science, PSLE Science, Secondary Science, O-Level Science and STEM education as a longform evidence-reading route; it is not medical advice, a laboratory protocol, an admission promise or a career guarantee.
Related eduKate reading: Monarch Initiative phenotype–gene–disease evidence; Human Phenotype Ontology and structured clinical phenotypes; ClinGen gene–disease validity evidence framework; Science Learning Hub; Education Hub; STEM Education; Careers by Subject Capability.
Primary and official sources checked on 11 October 2026: Official Matchmaker Exchange overview; Connected Matchmaker Exchange participants; Matchmaker Exchange Service Requirements, March 2026; Matchmaker Exchange rare-disease gene discovery study; 2026 Singapore–Cambridge O-Level Biology syllabus; MOE G2/G3 Lower Secondary Science teaching and learning syllabus; 2026 MOE G2 Computing syllabus. Resource interfaces and recommendations can change, so preserve the release, access date and documentation used.
| Stage | Question | Evidence | Responsible output |
|---|---|---|---|
| Prepare | What minimum permitted case representation can answer the question? | Candidate gene, phenotype, variant and consent settings | A governed query |
| Federate | Which connected services receive and evaluate it? | API connections, node capabilities and terms | Distributed match responses |
| Review | Why did each node call something a match? | Gene, variant, phenotype score, links and node protocol | A prioritised contact list |
| Validate | Do independent teams and data support one discovery? | Case review, consent, segregation, function and publication | A collaborative hypothesis, not an API verdict |
Inside this guide
1–12 · Foundations and design
- 1. Start with the rare-case problem
- 2. Understand federation
- 3. Understand connected nodes
- 4. Require a deposited case for querying
- 5. Use stable gene identifiers
- 6. Use structured phenotypes
- 7. Represent variants carefully
- 8. Minimise the query
- 9. Read consent before matching
- 10. Understand point-to-point connections
- 11. Expect different match algorithms
- 12. Do not compare raw scores blindly
13–24 · Models and estimation
- 13. Inspect exact gene matches
- 14. Inspect phenotype matches
- 15. Inspect variant matches
- 16. Read returned links and disclaimers
- 17. Understand notification protocols
- 18. Let humans review contact
- 19. Deduplicate cross-node cases
- 20. Separate match from gene discovery
- 21. Separate discovery from diagnosis
- 22. Use functional-study nodes carefully
- 23. Audit network coverage
- 24. Audit service availability
25–36 · Diagnostics and interpretation
- 25. Protect international data flows
- 26. Support withdrawal and correction
- 27. Use bounded clinical language
- 28. Connect to Primary Science
- 29. Connect to Secondary Science
- 30. Connect to mathematics
- 31. Connect to computing
- 32. Connect to pathways
- 33. Did you know?
- 34. Write a reader-ready result
- 35. Build a validation ladder
- 36. Finish with a reproducible bundle
Section 1 of 36
1. Start with the rare-case problem
A single rare presentation may be uninformative alone, while a genuinely similar independent case can clarify a candidate gene or phenotype expansion.
Working checkpoint — federated query: Define what similarity would support the hypothesis. Keep the initiating service, nodes reached, query fields, consent basis, responses and timestamps together.
For a classroom model, use fictional distributed card boxes and consent flags rather than personal data.
Section 2 of 36
2. Understand federation
MME connects databases rather than copying every case into one central repository. Queries travel between participating services through agreed interfaces.
Working checkpoint — connected node: Record the initiating node and queried nodes. Read each score inside its node-specific algorithm and scale; cross-node numbers are not automatically comparable.
For future study, connect federation to genetics, software, statistics and ethics while checking official pathways separately.
Section 3 of 36
3. Understand connected nodes
Participating services store different data types, serve different users and use different matching protocols.
Working checkpoint — candidate gene: Inspect the current participants table before assuming uniform coverage. Preserve failed requests, duplicate cases and near-matches; a final contact list is not the complete federated search.
For scientific writing, distinguish a candidate match, a validated collaboration and an established gene–disease relationship.
Section 4 of 36
4. Require a deposited case for querying
The March 2026 service requirements say services generally require users to deposit case data to undertake a federated query, with named exceptions for certain node types.
Working checkpoint — phenotype profile: Check the current requirement and local policy. Separate what the API matched from what collaborating teams verify and what experiments later support.
For students, ask: Which databases were searched, which were unreachable and why did each returned service call this a match?
Section 5 of 36
5. Use stable gene identifiers
Symbols can change, so candidate genes should use recognised identifiers where supported.
Working checkpoint — match notification: Keep identifier namespace and symbol together. Treat gene identifiers, genome builds, phenotype terms and node status as scientific data: a silent mismatch can hide or invent a hit.
For parents, a calm checkpoint is to ask what information crossed a boundary and who reviews a match before follow-up.
Section 6 of 36
6. Use structured phenotypes
HPO terms make profiles comparable across nodes, but specificity, negation and onset still matter.
Working checkpoint — consent boundary: Preserve the original observations and mapping process. Keep the initiating service, nodes reached, query fields, consent basis, responses and timestamps together.
For a classroom model, use fictional distributed card boxes and consent flags rather than personal data.
Section 7 of 36
7. Represent variants carefully
Coordinates, alleles, genome build, zygosity and consequence can distinguish a strong variant match from a superficial gene match.
Working checkpoint — federated query: Normalise without losing the submitted representation. Read each score inside its node-specific algorithm and scale; cross-node numbers are not automatically comparable.
For future study, connect federation to genetics, software, statistics and ethics while checking official pathways separately.
Section 8 of 36
8. Minimise the query
More detail can improve matching but also increases privacy risk and incompatibility.
Working checkpoint — connected node: Send only data necessary and permitted for the question. Preserve failed requests, duplicate cases and near-matches; a final contact list is not the complete federated search.
For scientific writing, distinguish a candidate match, a validated collaboration and an established gene–disease relationship.
Section 9 of 36
9. Read consent before matching
MME guidance distinguishes lower-detail matchmaking from sensitive phenotype or sequence-level sharing and requires attention to local jurisdiction and consent.
Working checkpoint — candidate gene: Verify the approved sharing level before the query. Separate what the API matched from what collaborating teams verify and what experiments later support.
For students, ask: Which databases were searched, which were unreachable and why did each returned service call this a match?
Section 10 of 36
10. Understand point-to-point connections
A federated network is not necessarily fully connected; a query may reach some nodes but not others.
Working checkpoint — phenotype profile: Save the actual destinations and response statuses. Treat gene identifiers, genome builds, phenotype terms and node status as scientific data: a silent mismatch can hide or invent a hit.
For parents, a calm checkpoint is to ask what information crossed a boundary and who reviews a match before follow-up.
Section 11 of 36
11. Expect different match algorithms
Nodes may match genes, variants, diagnoses, phenotypes or combinations and can weight them differently.
Working checkpoint — match notification: Read the node-specific matching protocol. Keep the initiating service, nodes reached, query fields, consent basis, responses and timestamps together.
For a classroom model, use fictional distributed card boxes and consent flags rather than personal data.
Section 12 of 36
12. Do not compare raw scores blindly
A score from one service may not share the scale, features or calibration of a score from another.
Working checkpoint — consent boundary: Rank within node unless cross-node calibration is demonstrated. Read each score inside its node-specific algorithm and scale; cross-node numbers are not automatically comparable.
For future study, connect federation to genetics, software, statistics and ethics while checking official pathways separately.
Section 13 of 36
13. Inspect exact gene matches
A shared candidate gene can be useful, but variant mechanism, inheritance and phenotype decide whether collaboration is meaningful.
Working checkpoint — federated query: Compare complete gene–disease models. Preserve failed requests, duplicate cases and near-matches; a final contact list is not the complete federated search.
For scientific writing, distinguish a candidate match, a validated collaboration and an established gene–disease relationship.
Section 14 of 36
14. Inspect phenotype matches
Phenotype similarity can rescue cases without the same candidate gene, yet broad or incomplete terms can create noisy results.
Working checkpoint — connected node: Open the terms driving similarity. Separate what the API matched from what collaborating teams verify and what experiments later support.
For students, ask: Which databases were searched, which were unreachable and why did each returned service call this a match?
Section 15 of 36
15. Inspect variant matches
A coordinate or consequence match may be strong, but assembly, transcript and representation errors can create false differences or false sameness.
Working checkpoint — candidate gene: Verify each allele on the same reference. Treat gene identifiers, genome builds, phenotype terms and node status as scientific data: a silent mismatch can hide or invent a hit.
For parents, a calm checkpoint is to ask what information crossed a boundary and who reviews a match before follow-up.
Section 16 of 36
16. Read returned links and disclaimers
Service requirements call for connected-database terms and disclaimers to accompany results.
Working checkpoint — phenotype profile: Keep them with the match record. Keep the initiating service, nodes reached, query fields, consent basis, responses and timestamps together.
For a classroom model, use fictional distributed card boxes and consent flags rather than personal data.
Section 17 of 36
17. Understand notification protocols
Some nodes show results immediately, some send email and some manually vet contact requests.
Working checkpoint — match notification: Do not treat silence as no match. Read each score inside its node-specific algorithm and scale; cross-node numbers are not automatically comparable.
For future study, connect federation to genetics, software, statistics and ethics while checking official pathways separately.
Section 18 of 36
18. Let humans review contact
A computational hit becomes useful only when authorised people compare cases, methods and evidence.
Working checkpoint — consent boundary: Document who reviewed and why contact proceeded. Preserve failed requests, duplicate cases and near-matches; a final contact list is not the complete federated search.
For scientific writing, distinguish a candidate match, a validated collaboration and an established gene–disease relationship.
Section 19 of 36
19. Deduplicate cross-node cases
One individual may appear in more than one system or publication, creating apparent replication.
Working checkpoint — federated query: Use approved cross-references to identify duplicates. Separate what the API matched from what collaborating teams verify and what experiments later support.
For students, ask: Which databases were searched, which were unreachable and why did each returned service call this a match?
Section 20 of 36
20. Separate match from gene discovery
Two similar cases can strengthen a hypothesis, but alternative genes, phenocopies and chance matches remain.
Working checkpoint — connected node: State the additional evidence needed for discovery. Treat gene identifiers, genome builds, phenotype terms and node status as scientific data: a silent mismatch can hide or invent a hit.
For parents, a calm checkpoint is to ask what information crossed a boundary and who reviews a match before follow-up.
Section 21 of 36
21. Separate discovery from diagnosis
A new gene association may still be uncertain for clinical reporting, and each variant needs its own interpretation.
Working checkpoint — candidate gene: Keep research and clinical decisions distinct. Keep the initiating service, nodes reached, query fields, consent basis, responses and timestamps together.
For a classroom model, use fictional distributed card boxes and consent flags rather than personal data.
Section 22 of 36
22. Use functional-study nodes carefully
Model organisms and functional evidence can help test mechanisms but are not human patient matches.
Working checkpoint — phenotype profile: Label evidence type and species. Read each score inside its node-specific algorithm and scale; cross-node numbers are not automatically comparable.
For future study, connect federation to genetics, software, statistics and ethics while checking official pathways separately.
Section 23 of 36
23. Audit network coverage
A negative federated search can reflect sparse deposition, missing connections, different identifiers or strict thresholds.
Working checkpoint — match notification: Report which nodes and data types were searched. Preserve failed requests, duplicate cases and near-matches; a final contact list is not the complete federated search.
For scientific writing, distinguish a candidate match, a validated collaboration and an established gene–disease relationship.
Section 24 of 36
24. Audit service availability
Timeouts, maintenance and partial failures can change returned matches.
Working checkpoint — consent boundary: Save response status and retry policy. Separate what the API matched from what collaborating teams verify and what experiments later support.
For students, ask: Which databases were searched, which were unreachable and why did each returned service call this a match?
Section 25 of 36
25. Protect international data flows
MME is designed for cross-border collaboration, so governance, security and donor expectations must travel with the data.
Working checkpoint — federated query: Record jurisdiction and approved purpose. Treat gene identifiers, genome builds, phenotype terms and node status as scientific data: a silent mismatch can hide or invent a hit.
For parents, a calm checkpoint is to ask what information crossed a boundary and who reviews a match before follow-up.
Section 26 of 36
26. Support withdrawal and correction
A case owner may update or withdraw data, while earlier notifications may persist.
Working checkpoint — connected node: Follow node procedures and propagate corrections where required. Keep the initiating service, nodes reached, query fields, consent basis, responses and timestamps together.
For a classroom model, use fictional distributed card boxes and consent flags rather than personal data.
Section 27 of 36
27. Use bounded clinical language
MME supports matchmaking and gene discovery collaboration; it does not diagnose or prescribe.
Working checkpoint — candidate gene: Say “candidate match returned”. Read each score inside its node-specific algorithm and scale; cross-node numbers are not automatically comparable.
For future study, connect federation to genetics, software, statistics and ethics while checking official pathways separately.
Section 28 of 36
28. Connect to Primary Science
A classroom network that searches several fictional card boxes shows why a distributed search can find a rare partner.
Working checkpoint — phenotype profile: Use invented data and explicit permission cards. Preserve failed requests, duplicate cases and near-matches; a final contact list is not the complete federated search.
For scientific writing, distinguish a candidate match, a validated collaboration and an established gene–disease relationship.
Section 29 of 36
29. Connect to Secondary Science
Inheritance, mutations and phenotypes explain why two cases must be biologically comparable, not merely visually similar.
Working checkpoint — match notification: Write the proposed mechanism and alternative. Separate what the API matched from what collaborating teams verify and what experiments later support.
For students, ask: Which databases were searched, which were unreachable and why did each returned service call this a match?
Section 30 of 36
30. Connect to mathematics
Similarity, ranking, false matches and network coverage turn matchmaking into a quantitative problem.
Working checkpoint — consent boundary: Test how rankings change when one broad phenotype is removed. Treat gene identifiers, genome builds, phenotype terms and node status as scientific data: a silent mismatch can hide or invent a hit.
For parents, a calm checkpoint is to ask what information crossed a boundary and who reviews a match before follow-up.
Section 31 of 36
31. Connect to computing
APIs, identifiers, distributed systems, logging and security policies make federation possible.
Working checkpoint — federated query: Treat schema and authentication failures as evidence limits. Keep the initiating service, nodes reached, query fields, consent basis, responses and timestamps together.
For a classroom model, use fictional distributed card boxes and consent flags rather than personal data.
Section 32 of 36
32. Connect to pathways
Federated rare-disease work joins genetics, software, statistics, ethics and international collaboration and can illuminate STEM pathways.
Working checkpoint — connected node: Check official programme requirements separately. Read each score inside its node-specific algorithm and scale; cross-node numbers are not automatically comparable.
For future study, connect federation to genetics, software, statistics and ethics while checking official pathways separately.
Section 33 of 36
33. Did you know?
A federated query can find a potential match without moving every database into one central store; the participating nodes keep their own systems and rules.
Working checkpoint — candidate gene: Distinguish discovery from data centralisation. Preserve failed requests, duplicate cases and near-matches; a final contact list is not the complete federated search.
For scientific writing, distinguish a candidate match, a validated collaboration and an established gene–disease relationship.
Section 34 of 36
34. Write a reader-ready result
A strong summary names initiating service, nodes reached, permitted inputs, algorithm context, matches, scores, contact status, evidence and limitations.
Working checkpoint — phenotype profile: Make the network path inspectable. Separate what the API matched from what collaborating teams verify and what experiments later support.
For students, ask: Which databases were searched, which were unreachable and why did each returned service call this a match?
Section 35 of 36
35. Build a validation ladder
Verify consent and identifiers, confirm node coverage, inspect match reasons, deduplicate cases, contact responsibly and test the gene–disease hypothesis independently.
Working checkpoint — match notification: Strengthen governance and biology together. Treat gene identifiers, genome builds, phenotype terms and node status as scientific data: a silent mismatch can hide or invent a hit.
For parents, a calm checkpoint is to ask what information crossed a boundary and who reviews a match before follow-up.
Section 36 of 36
36. Finish with a reproducible bundle
Deliver query representation, consent basis, node list, requests and responses, algorithm notes, match table, contact log, validation evidence and outcome.
Working checkpoint — consent boundary: Make every match and decision reconstructable. Keep the initiating service, nodes reached, query fields, consent basis, responses and timestamps together.
For a classroom model, use fictional distributed card boxes and consent flags rather than personal data.
Contents · Previous section · Continue to the Science Learning Hub