open-index/open-npm huggingface dataset:
npm package: @symtend/react
Description: A React utility library
Latest version: 1.0.0

# Symtend React

A React utility library.

## Contributing

```bash
# To install dependencies:
npm i

# To run tests:
npm t
# ...or:
npm run test

# To build:
npm run build
```

## Examples

```tsx
const registrationPhases: ["PERSONAL_DATA", "CONTACT_DATA", "VERIFICATION"] = [
  "PERSONAL_DATA",
  "CONTACT_DATA",
  "VERIFICATION",
];
const { phase, setNextPhase, setPreviousPhase } = usePhase(
  registrationPhases,
  0
);
```
npm package: @synanetics/document-db-serializer
Description: Document Database Serializer
Author: Will Robinson
Latest version: 1.0.1

# `@synanetics/document-db-serializer`

This packages provides serialization and deserialization functionality for storing and retrieving non JSON native JavaScript types in document databases.

## Usage

```typescript
import { serializeData, deserializeData } from '@synanetics/document-db-serializer';

const data: Data = {
    test: "test",
    url: new URL("https://www.example.com/"),
};

// serializeData return infers serializedData's type
const serializedData = serializeData(data);

// Write data to document database

// Read data from document database

// deserializedData's return is unknown, assert for subsequent data use
const deserializedData = deserializeData(readData) as Data;

// deserializedData is equal to data
```

## Currently Targeted Serializations
This package currently serializes the following JavaScript types:
- URL
- Date

To support more non JSON native JavaScript types, add to the `serializations` array and update the `Serialized` type.
npm package: @synanetics/fhir-transform
Description: Perform FHIR $transform operations
Author: Lee Campbell
Latest version: 0.10.6

# FHIR Transform Package
Performs FHIR $transform operations

## Features
Interprets FHIR StructureMaps and applies their transformations to the input parameter(s), performing cardinality corrections against a supplied StructureDefinition. The output resource(s) are explicitly not validated against the supplied StructureDefinition(s), as per the FHIR specifications.

## Example usage
```typescript
import transform from '@synanetics/fhir-transform';

const structureMap = {
  // structureMap FHIR resource
};

const content = {
  // source resource
};

// your structureDefinitionResolver can be as elaborate as you like, perhaps returning from a URL or a cache
const structureDefinitionResolver = async (url: string): Promise<any> => {
  switch (url) {
    case 'http://example.com/StructureDefinition/CustomResource':
      return {
        // profile definition
      };
    // whatever else
  }
};

// Your conceptMapResolver can be elaborate too, but needs to return the URL as the key object key.
// This is done so that you can choose to "follow" links to other ConceptMaps that may exist inside the
// first ConceptMap returned by the resolver.
const conceptMapResolver = async (url: string): Promise<Record<string, any>> => {
  const record: Record<string, any> = {};
  
  const map = await fetch(url);
  record[url] = await map.json();
  if (map.group[0].unmapped?.url) {
    const otherMap = await fetch(map.group[0].unmapped.url);
    record[map.group[0].unmapped.url] = await otherMap.json();
  }
};

// the structureMapResolver works exactly the same as the conceptMapResolver, so is not shown here.

const result = await transform({
  content,
  structureMap,
  structureDefinitionResolver,
  conceptMapResolver,
});
```

## Performance Benchmarking
Performing the `$transform` operation is both memory and CPU intensive, as large volumes of reference data need to be accessible in order to assert that data items are of the correct type and in order to perform [identity transforms](https://www.hl7.org/fhir/mapping-language.html#simple) according to their default mapping groups.

Introducing changes that degrade performance is unfortunately too easy. In order to offer some protection against that, there is a set of tests that will fail if memory consumption grows too much, or if total processing time increases beyond a set threshold. These tests should be taken _seriously_.

They will run as part of the usual suite and can be run separately using:

```sh
pnpm test:performance
```

Additionally, there is a script that performs a similar suite of tests, but produces a nicer-formatted output, with some additional metrics in it, which can be run using:

```sh
pnpm benchmark
```
npm package: @synanetics/iam-scope-parser
Description: IAM scope parser
Author: Alex Whitman
Latest version: 0.1.0

# `@synanetics/iam-scope-parser`

Parses and applies scopes against a list of targets.

## Usage

```typescript
import { parseScope } from '@synanetics/iam-scope-parser';

const result = parseScope('read:YHCR.* read:LLRCR.* !read:YHCR.DEF !read:LLRCR.ABC', 'read', [
    'YHCR.ABC',
    'YHCR.DEF',
    'YHCR.GHI',
    'LLRCR.ABC',
    'LLRCR.DEF',
    'LLRCR.GHI',
    'DDCR.ABC',
]);

console.log(result);
/**
{
    allow: [
        'YHCR.ABC',
        'YHCR.GHI',
        'LLRCR.DEF',
        'LLRCR.GHI',
    ],
    deny: [
        'YHCR.DEF',
        'LLRCR.ABC',
        'DDCR.ABC',
    ]
}
*/
```

## Detailed description

This package has been created to support the Interweave NRL project which requires providers to opt-in to data sharing with out-of-region consumers.
Scopes will be applied by the IAM service to generated JWT tokens and can be evaluated against a set of target providers using this package.

This package employs a deny-by-default approach where anything not matching a scope is automatically denied and deny rules take precedence.

## Examples

- `read:YHCR.* !read:YHCR.ABC` - This would allow reads from all consumers in the `YHCR` region, excluding the consumer with prefix `ABC`.
- `read:YHCR.ABC` - This would only allow reads from the consumer with prefix `ABC` in the `YHCR` region.
- `read:YHCR.* read:LLRCR.*` - This would allow reads from all consumers in the `YHCR` and `LLRCR` regions.
- `read:YHCR.* !read:LLRCR.*` - While this is a valid scope, the `!read:LLRCR.*` is redundant as it would be denied by default if not present.
- `read:YHCR.* read:DDCR.ABC` - This would allow reads from all consumers in the `YHCR` region and the single `ABC` provider in the `DDCR` region.
- `!read:YHCR.* read:YHCR.ABC` - This would deny from all as the `!read:YHCR.*` is a deny which takes precedence.

## Dependencies

This package has no dependencies outside of `vitest` for testing.

## Testing

```
npm run test
```
npm package: @synanetics/messaging-processor
Description: Processors to manage FHIR MessageHeader bundle workflows
Author: David Tolman
Latest version: 3.2.10

# `@synanetics/messaging-processor`

Processors to manage FHIR MessageHeader Bundle workflows

## Usage

```
const { preProcess, postProcess } = require('@synanetics/messaging-processor');
// use a required
```

Both `preProcess` and `postProcess` require parameters `context` and `params`. Please see the available [types](./src/types.ts) for further details

## Replacement

It is intended that this package can be replaced by another. Any replacement must export two named functions `preProcess` and `postProcess` and they must adhere to the interfaces outlined below.

### Pre Processing

`preProcess`
  * will receive params
    * `context` - see type [Context](./src/types.ts)
    * `params` - see type [ProcessorMessage](./src/types.ts)
      * `message` - this is the Request bundle for processing
  * must return results - see type [ProcessorResult](./src/types.ts)
    * `message` will be your modified request Bundle
    * `additionalResources` must be populated with any resources subject to create/update operations that are not already in the request Bundle. **This is vitally important as failure to include this will result in removal of the modified resources entirely.**

### Post Processing

`postProcess`
  * will receive params
    * `context` - see type [Context](./src/types.ts)
    * `params` - see type [PostProcessorMessage](./src/types.ts)
      * `message` - this is the Response bundle being sent back
      * `request` - this is the original Request bundle - you will use this to determine flow hooks if necessary
  * must return results - see type [ProcessorResult](./src/types.ts)
    * `message` will be your modified response Bundle
    * `additionalResources` must be populated with any resources subject to create/update operations that were not already in the request Bundle. **This is vitally important as failure to include this will result in removal of the modified resources entirely.**
npm package: @synanetics/profiles-nrl
Description: FHIR Profiles for the Interweave NRL integration
Author: Alex Whitman
Latest version: 1.7.0

# `@synanetics/profiles-nrl`

> Profiles / resources that support Interweave NRL integration.

## FHIR Mapping Language

`src/ips-composition.map` is a FHIR Mapping Language map file to create a StructureMap for converting a source Bundle into an IPS Composition Bundle.

### Compilation

The map file can be converted into a StructureMap by using the `@synanetics/fhir-fml-convert` package.

## Liquid Template

The Liquid template defined within this repository is now published to the R4 Metadata Store (https://fhir.yhcr.nhs.uk/fhir/r4/DocumentReference/nrl-html-template). Interweave manage this template, so it is expected to fall out of sync with the template in this repository. The template in this repository was a first-pass for testing/approval purposes.

The styling in the Liquid template is taken from the NHS's Design system, found here: https://github.com/nhsuk/nhsuk-frontend.

At time of writing, we are using the latest version, [10.3.1](https://github.com/nhsuk/nhsuk-frontend/releases/tag/v10.3.1).
npm package: @synanetics/profiles-pie
Description: FHIR Profiles for the Synanetics Pathology Integration Engine (PIE)
Author: Lee Campbell
Latest version: 5.5.0

# `@synanetics/profiles-pie`

> A set of FHIR profiles, constants and types that support PIE.

## Usage

### Constants and Types

Constants and types can be imported directly.

e.g:
```typescript
import { 
  RoutingRuleTargetMapping,
  serviceRequestFillerGroupNumberSp,
} from '@synanetics/profiles-pie'

const mapping: RoutingRuleTargetMapping = {
  receiver: {
    reference: 'Endpoint/12345',
  },
  processDefinition: [
    {
      reference: 'PlanDefinition/101010',
    }
  ];
}

const fgnCode = serviceRequestFillerGroupNumberSp.code; // -fgn

```
### Profiles
- Profiles are compiled into `.json` files and exported into the dist folder of the package
- To utilise the PIE profiles, import the `.json` files into the custom schema directory of your Connect appliance/adapter